Эта статья будет использована для подведения итогов по статье про идеальное место работы ЗУПера.
В первой части рассмотрели негативные тенденции и лишние для ЗУПера компетенции.
Идеальное место работы для ЗУПера... Какое оно?! Часть 1. Негативные тенденции, ненужные знания.
Во второй части рассмотрели способы оценки реальных и важных компетенций ЗУПера.
Идеальное место работы для ЗУПера... Какое оно?! Часть 2. Как оценить специалиста ЗУП
Если Вы не читали первые 2 части про работодателей, то вот ссылки:
Адекватность работодателя. Как её определить? Часть 1. Собеседование, заключение трудового договора
Вроде бы уже описал все косяки в процессе работы, но чего-то не хватает. Со временем стало понятно, что "навыки" РПшников и тимлидов заслуживают отдельной статьи. Как и в прошлых статьях, всё написанное основано на моём опыте работы. Через всё это пришлось пройти и хочется, чтоб остальным не пришлось!
Рассмотрим главные "особенности" управления проектами, опишу их по частоте встречаемости. Чтоб не ругаться матом, и никого не называть своими именами, заменю это на народные выражения. В этой статье описано, как не надо вмешиваться в процесс работы команды:
1. Я уже пообещал... или "Кто в кони пошел, тот и воду возит!"
2. Да, да, обязательно и это сделаем в срок! или "Девять женщин за месяц не родят!"
3. Я тоже раньше программировал... Эту задачу я сделал бы за "икс" часов или "я угадаю эту мелодию с трех нот".
4. У Вас бардак просто потому, что не автоматизирована работа по задачам... Нужен автоматизированный бардак.
Теперь подробнее по каждому пункту:
1. Я уже пообещал... или "Кто в кони пошел, тот и воду вози!"
Уверен, что к каждому из нас, хотя бы раз (в день/месяц) подходил РП или тимлид с этой фразой.
На мой взгляд, эта фраза, ни что иное, как попытка построить мотивацию в коллективе на собственной глупости и необразованности. Никак иначе это объяснить невозможно. Что двигает такими людьми руководителями:
- Желание вылизать до блеска некоторые части тела вышестоящего руководства или заказчика. Думают, что премия прилетит... Прилетит... но не премия!
- Создать мотивацию для всей команды или для отдельных её сотрудников. Некоторым подобная чушь вообще прилетает в виде KPI.
- Устаревшие с годами знания создают иллюзию того, что это элементарно и быстро сделать.
- Ранее он руководил SAP, Oracle, Axapta и прочими зарубежными системами. Такой опыт опять же создаёт иллюзию того, что разработчик - это почти оператор. Вот напиши ему ТЗ грамотное и он тупо всё накодит. Разработчику не важно где кодить, язык одинаковый во всех конфигурациях.
А вот что на самом деле получается в результате:
- Приходится идти в аптеку за смазкой, или на рынок труда! Ибо балаболов никто и нигде не любит!
- Приходится искать новых сотрудников, иногда много... Смотря как сильно хотел замотивировать, может вся команда ушла)))
- В лучшем случае появляется КОСТЫЛЬ! Чтобы первые 2 пункта не стали актуальным. Думаю не надо рассказывать сколько стоит обслуживание костылей!? Уже большинству это хорошо известно.
- Начинается игра "Горячая картошка". Т.к. уже точно подгорает, замотивированные разработчики и аналитики начинают кидать друг в друга задачу. Количество итераций перед успешным её завершением очень большое! С какого раза может разработчик, не знающий ЗУП успешно сдать задачу, которая не отчет и не печатная форма?!
- Результатом всех этих игр становится, в лучшем случае, отсутствие бюджета на премию, в худшем на зарплату)
Что хочется таким чудесатым руководителям сказать?!
Сам пообещал, сам и делай! Или как гласит народная мудрость: "Кто в кони пошел, тот и воду возит!"
Примеры из моей практики:
- Работал в интеграторе, который уже развалился) Интегратор занимался сопровождением, с перспективой получить проект внедрения. Была задача обновить отчетность какую-то. Я подошел к этой задаче фундаментально: добавил новую форму, перенес и отладил нужные для её сдачи модули, внёс изменения по конфигурации... Да, я потратил на это 2 недели. И был готов отдать задачу в понедельник утром. Т.е. за выходные я бы закончил. Уже отчетность формировалась, нужно было пару моментов шлифануть и идеально. И тут звонит РПшник, устраивает панику. Это пятница утро. Орёт, если сегодня не будет к вечеру, Я ПООБЕЩАЛ, то типа уже и не надо... И на этой волшебной волне он поручил задачу другому. Тот сделал костыль практически бесполезный и закрыл задачу как и желал РПшник до вечера пятницы. Самое волшебное в этой ситуации: то что я сделал, т.е. полностью рабочий вариант, который далее легко сопровождать - положили в мусорку)
- Интересный случай был на металлургическом заводе. РП со стороны заказчика - это начальник отдела труда и заработной платы (ОТиЗ), по совместительству - родная сестра генерального директора. Часто возникали ситуации, раз в неделю точно, где она пообещала кому-то что задачу сделают образно либо завтра, либо до конца недели. Комичность ситуации в том, что человек невероятно далёк от сферы ИТ и MS-DOS назывался ласково "дося") С таким сталкивался не раз, когда по сути, функциональный заказчик устанавливает неадекватные сроки и транслирует их более высокому руководству.
Всегда можно поступить более нормально:
- Не вешать лапшу на уши!
- Посоветоваться с архитектором или со всей командой, согласовать трудоёмкость задач.
- Обновить свои знания устаревшие.
- Подбирать персонал, который "в теме".
Для специализации ЗУП предлагаю почитать статьи:
-- Я - ЗУПер! Часть 1. Компетенции сотрудников.
-- Идеальное место работы для ЗУПера... Какое оно?! Часть 2. Как оценить специалиста ЗУП
2. Да, да, обязательно и это сделаем в срок! или "Девять женщин за месяц не родят!"
Бывают такие добрые и заботливые РПшники и тимлиды... Они очень заботятся о настроении заказчика. Но забота эта идёт любой ценой в разрез с адекватностью.
Если немного утрировать, то задача руководителя сделать так, чтобы побольше задач было выполнено и поменьше за них было заплачено. Часто к этому добавляется ещё требование сократить количество невыполненных задач как можно быстрее. Вот тут и начинается выступление... Выслушав цели от высокого руководства, РПшник, начитавшись бесполезной зарубежной литературы вроде PM Book, говорит:
- Эту задачу сделаем, и эту сделаем, и постараемся ещё вот это, это и то...
- Чтоб ускориться по крупной задаче, мы её разобьём на маленькие части, все ресурсы бросим на её решение, за два дня сделаем
- Там где не хватает ресурсов, мы возьмём мидлов "500 штук" и закроем проект за "неделю"
- Возьмём на субподряд команду какую-нибудь...
Вроде ж всё делает правильно, как написано в книге заморской... Должно всё получиться. Но получается вот так:
- Навешали лапши на уши уставшему заказчику, чтоб его успокоить, дать надежду... Но вместо рыцаря в доспехах оказались известным в русском языке персонаже в фольге!
- Задачу разбили, людей всех кинули на амбразуру... Половина не вкурила, что надо было делать, и сделали плохо. Остальные задачи, в которые все были погружены застопорились. После возврата к задаче потеряли время, чтоб вспомнить всё, что делали ранее. Просрали кучу времени, результат не получили.
- Поиск хороших разработчиков с уровнем мидл+ занимает не мало времени, особенно если это ЗУП) Уверен все с этим сталкивались. Чтоб быстро набрать нужное количество кривых рук - взяли мидл минус! Бюджет профукали, новички в задачи долго вникали, сделали не очень качественно. Всё равно надо искать нормальных и всё переделывать. Опять встаёт вопрос, а почему же нет премий)
- Популярная тема давать в аренду людей и за результат их работы не отвечать))) Стоит дорого, толку никакого, время в пустую. В ответ слышим: "Ну Вы же сами ему задачу ставили, сами выясняли у заказчика, мы ни причём!" Персонаж в фольге покупает банку вазелина и идёт на рынок труда вешать лапшу очередному работодателю.
Таким персонажам напомним очередную мудрость: "Девять женщин за месяц не родят!" Особенно это важно в задачах, которые нельзя разбивать и отдавать другим разработчикам.
Как можно поступить "по уму":
- Выделить ключевые задачи, не обещать ничего на совещании
- Оценить трудоёмкость задач, сравнить с имеющимися ресурсами
- Оценить важность выполняемых в текущий момент задач, перераспределить ресурсы
- На сотрудников с уровнем мидл минус перенаправить простые задачи, не задействовать их в выполнении ключевых задач.
Простую, но понятную классификацию задач приводил с примерами в статье:
Я - ЗУПер! Часть 2. Классификация проектов и задач
3. Я тоже раньше программировал... Эту задачу я сделал бы за "икс" часов или "я угадаю эту мелодию с трех нот".
В нашем королевстве кривых зеркал, называемом "мир 1С" есть одно невероятное заблуждение...
Почему-то считается, что разработчик/консультант может стать руководителем проекта, и это ещё называется карьерным ростом. Неужели, те кто эту чушь пишет у себя в вакансиях не понимают, что это СМЕНА ПРОФЕССИИ, а не карьерный рост!? Картинка к публикации ровно об этом). И вот, где-то лет 10 назад, благодаря этому великолепному заблуждению, выродилось очень много бывших разработчиков-руководителей проектов. Эти чудесатые специалисты обладают невероятными качествами:
- Многие стали руководителями просто чтоб ими никто не руководил. Т.е. люди которые не умеют сами выполнять поручения теперь их раздают остальным
- Все кто не состоялся как разработчик/консультант (теперь ещё и аналитики) и не смог перешагнуть планку мидл начали карьерно расти. Лучше бы росли профессионально!
- Получается абсурд, начинающие РП требуют зарплату выше чем профессиональные разработчики. Надо сказать, что сейчас рынок подравнял этих карьеристов, всем стало понятно, что не РП делает проект. Давайте тогда профессионального фрезеровщика поставим руководить проектами?! Почему бы и нет? Какая разница из каких компетенций потом лепить РПшника?! Всё равно эти компетенции практически не пересекаются.
- Вообще не знают ничего об управлении проектами. Их стиль можно выразить фразой: "Буду руководить не так, как руководили мной". И надо отдать должное, обычно действительно получается не так, а гораздо хуже! Ведь ими руководили люди, которые хотя бы PMBook листали, а некоторые прошли через аттестацию. В хорошем варианте владеют несколькими методиками управления и применяют "гибкие практики".
- Навыки программирования у этих людей застряли либо на платформе 8.2, либо вообще на 7.7! И люди, которые не пытались ни разу вести разработку на управляемых формах с использованием программного интерфейса, начинают рассказывать, что задача не сложная. Особенно интересно это выглядит, когда эти люди с умным видом задают устаревшие вопросы. Что-то вроде: "А что будет, если через точку в запросе...".
Если кому-то показалось, что я изначально негативно отношусь ко всем РПшникам - ПОКАЗАЛОСЬ! С уважением отношусь к профессионалам в любой сфере. Профи отличается от того, что я описал одним простым качеством - ему важно ДОСТИЧЬ РЕЗУЛЬТАТ, а не чтобы ВСЕ СДЕЛАЛИ КАК ОН СКАЗАЛ. Это главное отличие.
Ну и собственно когда генерал диванных войск с устаревшими знаниями говорит, что сделает быстрее - всегда отвечаю: "Иди делай!".
Есть же и нормальный путь развития руководителя проектов, который неоднократно наблюдал в процессе работы:
- Понимая, что РП - это другая профессия, в неё вникают ЗАРАНЕЕ. Изучают PMBook, сдают аттестацию, продолжая работать по своей специализации (разработчик, аналитик, консультант).
- Если работодателю хочется показать, что есть карьерный рост:
- Позиция технического архитектора является карьерным ростом для разработчика
- Позиция функционального архитектора является карьерным ростом для аналитика/консультанта
- Даже при нормальном карьерном росте в сторону архитектора необходимо глубже изучать предметную область, инструменты, архитектуру решения ЗАРАНЕЕ.
- Если есть желание ускорить разработку по какой-либо задаче, единственный путь - вникнуть в задачу, понять где проблемные точки, предложить обоснованное решение.
Кто такой архитектор, описывал ранее в статье: Кто такой архитектор?
При таком подходе не придётся вспоминать передачу Валдиса Пельша "угадай мелодию". И на фразу "Я угадаю эту мелодию с Х нот" отвечать "УГАДЫВАЙ!"
4. У Вас бардак просто потому, что не автоматизирована работа по задачам... Нужен автоматизированный бардак.
Наверняка многие сталкивались с ситуацией, когда приходит на крупный проект новый начальник и думает, что "Новая метла чище метёт". По мнению некоторых, если 500 задач вписать в какую-то волшебную программу, что 400 из них решатся сами собой. Тут не поможет ни расширение штата, ни убеждение заказчика, что как минимум половина задач не нужны совсем или сейчас не нужны. Как только начинаешь обсуждать детали, то начинают сыпаться на вопросах:
- Кто внесёт единоразово весь список задач в волшебную программу? Почему-то сам РП считает что не царское это дело и участвовать в этом не собирается)
- Дальше логично предложить принять кого-то на работу. В ответ - бюджет проекта не позволяет это сделать!
- Начальник предлагает ВСЕМ подзадержаться после работы или потратить выходные дни на удовлетворение его хотелки. Оплачивать обычно не желает. Тут можно услышать сказки про какую-то премию, которая вряд ли светит)))
- Кто будет отслеживать всё это!? На этот вопрос повторяются 3 вышестоящих пункта.
Как итог - это не взлетает) Конечно, хорошо, когда сразу все задачи где-то фиксируются и есть например тимлид разработки (это не архитектор!), или ещё какой-то выделенный менеджер.
На эту тему читал несколько статей у Ивана Белокаменцева. Честно, не помню, как называются.
Вопрос решается очень просто:
- Есть объём работы, который надо выполнить, значит должен быть бюджет на его выполнение! Бесплатный сыр в мышеловке!
- Либо оплачиваем переработки, либо предусматриваем в проекте условного менеджера для обслуживания этих задач.
Если Вы не знаете, как поставить плюс или зачем это вообще делать, для Вас статья:
Публикации с полезными обработками:
Универсальный шаблон для загрузки данных из Excel и подбора ссылок в любой конфигурации
Пример работы с файлами odt в клиент-серверной модели работы
