Уже писал про не самую удобную схему, когда команда sale у подрядчика одна, а исполнять и работать дальше с Заказчиком даётся другой команде - это и непонимание целей, и отсутствие в голове логов коммуникации и договорённостей - всё решается, но Заказчик вынужден тратить время и прилагать усилия на то, о чём он уже ранее договорился. Зачем?!!! Непонятно...
Компания, на минуточку, входит в ТОП-3 в сегменте российской заказной разработки программного обеспечения (по мнению одного весьма продажного новостного ИТ агенства). 1000+ проектов за пару десятков лет (тут не удивишь, у меня у самого с моими командами под пару сотен реализованных R&D проектов). 1000+ разработчиков. Широкий техстек.
Ну ок, вместо продажного менеджера теперь у нас есть KAM - Key Account Manager - а вместо группы экспертов во главе с тех диром - проджект менеджер. Нам их представили и отправили в добрый путь.
Задачи КАМ стали сводиться к участию в совещаниях с Заказчиком и выставлению счетов за потраченные трудоресурсы. Главное, как говорится, вовремя счёт выставить. И денежку на счету увидеть.
Назначенный внутри компании Руководитель Проекта взялся за дело рьяно - собрал с коллег декомпозицию задач и начал проводить совещания с ними пару раз в неделю - он был один в двух лицах, и тимлид, и техлид. Его основным плюсом было погружение в технику и желание работать.
Минусы проявились сразу - несмотря на крутые заявления компании на рынке про "лучшесть" и "качество" среди прочих, план он составить не мог. Вот совсем не мог. Никаких диаграмм Ганта, никаких табличек или хотя бы приоритезации - в лучших традициях agile, а то и scrum берёт листик из левого ряда и перекладывает его вправо. Потом другой. Потом ещё - и так далее. Потом доходит до листика, для реализации написанного на котором требуется что-то купить и сообщает Заказчику - вот, надо, купи, а то мы завтра не продолжим. Купить можно только в Китае, срок поставки выясняется 100500 лет. Аналогов нет.
Раздаётся логичный вопрос Заказчика - А что, вы раньше не знали, что это потребуется купить?
- Ну...
- И почему не сказали заранее?
В ответ - бе, ме. Не подумали, вобщем.
- Так может, план наконец составите? - не унимался Заказчик.
- Составим! Обязательно составим - погорячился Проджект Менеджер подрядчика. Но потом.
- Когда?
В ответ - бе, ме...
Боже, если проектный менеджер разработки в компании ТОП-3 в России по заказной разработке ПО не в состоянии составить план хотя бы даже на месяц, не говоря уже о его исполнении и контроле, то становится страшно за отрасль и вообще за страну. Рыночная отрасль - это не только крутые свежие идеи, рождённые в головах уникальных инженеров, это ещё и реализация ДО того, как с такими же - а то и лучшими - идеями рынок завалят конкуренты.
Так и хотелось познакомить компанию, лидера отрасли (ага...) с инструментами управления.
Ганта проект-менеджер всё-таки родил, и даже несколько раз попытался ему следовать. Но... важно не только его иметь, но важно держать его актуальным, а этого коллеге не удавалось.
Контроль исполнения задач тоже был на "высочайшем" уровне. Типичный диалог внутри команды, когда мы туда влезли, чтобы разобраться в реалиях, был обнаружен примерно на таком уровне:
- А ты уже взялся за эту задачу?
- Нет
- А когда возьмёшься?
- Ну не знаю.
- Ну ладно.
- А у тебя как, всё по плану?
- Ага.
- Хорошо.
- А ты эту задачу сделал?
- Делаю.
- Ну и хорошо.
В итоге после целого ряда претензий по процессу ведения проекта и откровенно отрицательных оценок в анкете обратной связи, был выдан другой проект-менеджер. На этот раз проблема внутри компании выявила другой перекос - вновь прибывший составлял планы, актуализировал срезы, собирал встречи и вёл адекватную коммуникацию, но...
Новый РП-шник НИЧЕГО не понимал в технике (как минимум, этого проекта). Ему что-то вешали на уши - а вилок, чтобы снимать лапшу с ушей, у него не было. Наконец мы плюнули и потребовали проводить с Заказчиком и командой разработки совещания на ежедневной основе до стабилизации процесса.
Заказчик погрузился в верхнеуровневые тонкости сборки в сборочной среде, в последовательность разбора проблем брингапа - первичного запуска устройства с софтом - в проблемы реализации графического меню устройства и увязки с бэком. Зачем?
Потому что выяснилось сразу же, что принятые вчера на встрече решения исполнителями не выполнялись - они видели какую-то другую, более интересную им задачу, и делали её, с пеной у рта доказывая на следующий день, что да, вот так, это конечно правильный шаг. А то, что надо не то чтобы хотя бы утвердить этот шаг, но о нём желательно бы известить остальную команду, ждущую результат по заранее оговоренному плану - это в голову разработчику не приходило. Ведь он же самый умный, а другие все такие дураки и не понимают высокий полёт его мыслей. Ну и в целом, на совещаниях с точки зрения синхронизации технических задач происходила какая-то несусветная дичь...
Это, кстати, обычное явление, с которым приходится сталкиваться в этой среде, и панацея только одна - ежедневно делать срез, даже если работают ветераны ИТ отрасли. Нет, если надо сделать сайтик, или приложение для смартфона - то такое не требуется - а вот когда приходится совмещать разноплановые направления ИТ в одном проекте, то без этого никак - слишком сложным стал современный мир, чтобы разработчик мог заявить - да легко, я это уже не раз делал. Нет, не делал. Ты ещё не пытался собирать вот ту систему вот с этой библиотекой в условиях другой архитектуры центрального процессора и ограниченного объёма памяти.
Поэтому, предложения, идеи и методы ребят часто выглядели именно как "завтра всё будет" - и побежал строить летучий корабль с фразами "а мне летать, а мне летать, а мне летать охота"... В одиночку, за ночь. Но чуда не случалось, и не то что летучий - корабль тоже не получался. Хорошо, если хотя бы весло или парус...
Спасение Заказчика было только в ежедневном контроле поставленных задач. Лично заказчиком!!! Который шёл по списку и снимал статус по каждой мелочи, а мелочи все вместе выстраивались в единую конструкцию.
Проектный менеджер этой прекрасной аутсорс-компании тоже не справлялся, потому что идею двуглавого орла (что в стройке, что в ИТ разработке) никто не отменял. Нужен Тим лид, нужен Тех лид, и оба должны быть на проекте, иначе не срастается.
============
Подписывайтесь на канал - зарисовки выходят каждый день.
Ставьте лайк, если понравилось