13 ошибок в проекте

По прочтении всех историй проектов нашего мега-конкурса, мы обратились к хорошо известному эксперту по управлению проектами Ивану Селиховкину с вопросом: ПОЧЕМУ?! Почему так происходит? Что приводит к такому количеству человеческой боли?
Как обычно, дело оказалось в конкретных ошибках в проектах. Вариантов таких ошибок набралось 13. Несчастливое число, так и последствия у ошибок так себе… Итак…

13 ОШИБОК В ПРОЕКТЕ

Иван Селиховкин
ОШИБКА №1. «Работа втемную» (согласиться работать без фиксации договоренностей)
В ИТ так бывает очень часто. Пока одна половина ИТ-вселенной страдает, что заказчик не дает работать без тщательного ТЗ, в другой половине дела обстоят иначе. Заказчику или вашему директору не нужно от вас методологий. Ему нужно «чтобы работало».
Он верит, что вы = профессионал (с большой «П»). Открыто говорит: «Что нам там бюрократию разводить, я тебе задачу в целом обрисовал?! Не подведешь? Ну, давай!».
Бывает, что «ну давай» не предполагает сроков. И вообще оно расплывчатое. Соблазн менеджера — ответить «давай» и пойти работать. По молодости на эти грабли наступал многократно, и только потом научился осторожности (т.е. это очень коварные грабли).
Опытный менеджер ответит: «Я правильно вас понял, что нужно сделать вот то и вот то с такой целью?» и: «Следующим шагом мы с коллегами прикинем, и я сегодня-завтра сориентирую вас по срокам (когда будет первый результат, когда второй и когда все закончится)», и: «а также сколько нам потребуется людей, какая информация, как часто будем дергать вас».
Не сделаете этого, и работа без фиксации договоренностей через несколько месяцев превратится в испорченную карму. Милый заказчик выпьет из вас кровь. Директор обидится и скажет как вы его подвели, ведь он думал вы профессионал, а вы… Это произойдет не со зла, а по законам природы. Всегда уточняйте договоренности, фиксируйте их, даже если об этом не просят. Особенно если не просят.
ОШИБКА №2. Избегать конечных пользователей
На проекте бывает много заинтересованных сторон. Бывает и так, что некоторые из них большие шишки, а другие – нет. Не всегда, но часто «не шишки» — как раз и есть конечные пользователи. Вы работаете для них. Ваш продукт для них. И вот с ними сложнее всего.
Им плевать сколько стоит проект, о чем вы договорились с большим боссом, им работать. Им в этом жить. Нередко «большой босс» гораздо лояльнее «конечных пользователей».
Одна из самых крупных ошибок – думать, что вы сможете сделать успешный проект, не спускаясь на землю. Идите к пользователям. Собирайте их обратную связь, делайте пригодный продукт. Чего бы вам это не стоило.
ОШИБКА №3. «Подальше от начальства, поближе к кухне» (ходить только с просьбами)
«Армейский» принцип — чрезвычайно токсичный для управления проектами. Большинство из нас не любит без нужды соваться к начальству (будь то свой руководитель или представитель заказчика). Что происходит в итоге? Руководитель проекта «дрессирует» руководителя, вырабатывает у него рефлекс: если мое лицо появилось в дверях — несу дурные вести (иначе бы не пришел). «Дай людей», «подвинь срок» и т.п.
Контринтуитивная вещь, которой стоит научиться любому руководителю — заставить себя заходить к начальству с хорошими или нейтральными новостями. Ненадолго, ненавязчиво, в формате «я только на секунду — хотел сказать, что проект идет по плану, а по одной из вех мы, возможно, опережаем график, да и пользователи текущим релизом довольны».
Дайте шанс «начальнику» перестать вздрагиваться при виде вашего лица от предчувствия проблем («Шо, опять?» (c)). Если (когда) на проекте случатся настоящие проблемы — у вас будет задел его лояльности.
ОШИБКА №4. «А вы вообще кто?» (быть незаметным)
Одна из самых страшных вещей, которая может случиться с руководителем проекта — вас не помнят и не узнают. Вы берете слово, представители заказчика (или вашего руководства) уточняют вполголоса: «Это кто?..».
Роль руководителя проекта явно дается в руки только в очень зрелых компаниях (где такое назначение автоматически наделяет вас полномочиями и ответственностью, о которых не дадут забыть). В большинстве случаев вам нужно напоминать о себе «я руководитель проекта, и мне, коллеги, нужно запланировать 1-2-3 часа вашего времени для…», «мне нужно показать вам, получить, уточнить и т.п.».
Реакция «а кто это?», скорее всего означает: вы не были активным менеджером и уже находитесь на обочине (вы не ведете проект, у вас не так много полномочий, в худшем случае вам уготована роль «стрелочника»). Хотите играть роль менеджера — начинайте вести себя как менеджер, не бойтесь быть заметным.
ОШИБКА №5. «Пряничный домик» (чрезмерно верить в самомотивацию людей)
Гибкие и бережливые подходы поставили (во многом справедливо) во главу угла адекватность команды. Способность ее к самоорганизации. Способность отдельных людей — к самомотивации. Однако, возводить ее в абсолют так же нелепо, как, например, верить, что каждый человек стремится помогать ближнему. Люди — разные.
Некоторые психологи утверждают, что характер закладывается к трем годам и потом уже существенно не меняется. Важно понимать: некоторые люди НЕ способны к самоорганизации (это не значит, что они плохие инженеры). Кто-то нацелен использовать коллективную ответственность для личной безответственности (их лучше удалять из команды). Мир не белый (но и не черный). Люди не в один момент становятся командой.
Дайте коллективу общую цель, свободу и кредит доверия, и, как минимум, в пяти случаях из десяти результат разочарует. Менеджмент предполагает ответственность внутри команды, в том числе, личную. Предполагает не только «пряник», но и «кнут» (в смысле ответственности за свою работу). Из одних пряников роль ПМ не построить.
ОШИБКА №6. «Взять все и поделить» (упрощать бюрократию на проекте чрезмерно)
Прямое следствие предыдущего пункта. Управлять проектами трудно потому, что решаются сложные задачи, а в команде — разные люди. И для того, и для другого десятилетиями изобретались приемы, системы мотивации, системы контроля. Некоторые из них применимы только для неквалифицированных рабочих на сталелитейных заводах, другие же актуальны по сей день.
В любом случае, существует необходимый минимум проектной бюрократии. Взять и отменить все дурацкие бумажки и диаграммы Ганта — мечта многих инженеров и, наверное, неплохой предвыборный лозунг. Однако, полная отмена бюрократии невозможна. Решения должны фиксироваться (иначе о них тупо забывают), задачи должны отслеживаться. Если вашим проектом интересуется корпоративный юрист, бухгалтер, фин. директор — с ними возникает свой документооборот.
Нужно пресекать неоправданную бюрократию, но не нужно стремиться искоренять ее на корню. Мой опыт говорит: нередко попытки отменить бюрократию совсем приводят к ее разрастанию.
ОШИБКА №7. Не работать с командой, бояться ее (удел ИТ менеджеров не из инженеров).
По статистике менеджеры проектов в ИТ в 50% случаев это выходцы из бизнес-аналитиков и тестировщиков. А среди них, в свою очередь, немало людей пришедших в ИТ из гуманитарных и естественнонаучных специальностей (Иван, например, по первому образованию врач и только по второму — программист).
Общая проблема таких людей — опасаться команды инженеров. Сложно спорить с тем, в чью область ты пришел без образования. Опыт говорит: это путь к провалу. У менеджера полно своей (не инженерной) работы, которую никто в команде делать не хочет (ПМ на переднем крае, на него замыкаются многие конфликты и претензии, он «огребает», он выбивает людей на проект, он отстаивает принятые решения, он ведет к компромиссу тех, кто никакого компромисса не хочет и т.п.).
Правда в том, что для того, чтобы быть менеджером, вы не обязаны быть инженером, но должны уметь слушать своих людей, отличать правду от вранья, вызывать доверие. Так вылезайте же из раковины и работайте с командой. Не бойтесь ее — это единственный шанс.
ОШИБКА №8. Работать за команду, не доверять ей (удел ИТ менеджеров, вышедших из инженеров).
У бывших инженеров другая (классическая) беда. Сводится которая к формуле «зачем мне сто раз объяснять, если все равно сделают завтра и хуже чем я за пару часов».
Один мой знакомый тим-лидер действовал так: он играл роль менеджера пока это было не критично. Его команда работала по SCRUM, спринт две недели. Так вот, знакомый давал коллегам работать, но в последние два дня перед релизом садился и все героически допиливал сам. Со временем это расслабило команду, героических усилий коллеги перестало хватать, и проект поплыл, а он оказался крайним (хотя пахал больше всех).
Выход простой. Не работайте за других. Дайте команде провалиться. Это не так страшно, как кажется. Все должны понимать: это взрослый мир, ответственность существует. Провал возможен.
ОШИБКА №9. «Ботан» (чрезмерно верить цифрам).
В ИТ еще одна «болезнь» менеджеров — чрезмерно увлекаться показателями. Дисперсия, среднеквадратичное отклонение, анализ Монте-Карло. Я сам – отчаянный любитель таких методов, т.е. да, немного «ботан».  В менеджменте оценки по определению не бывают точнее чем от -5 до +10% (а на старте проекта и вовсе +-50%). Математика помогает, но не меняет ситуацию радикально. На вход любой формулы (пресловутой оценки по трем точкам или анализа Монте-Карло) вы все равно подаете экспертные оценки. Т.е. мнения (свои или других людей, или наблюдения из базы знаний).
Если мнение ошибочно, результат не достоверен. Правило «мусор на входе — мусор на выходе» никто не отменял. Используйте математику, но не давайте ей одурачить вас.
ОШИБКА №10. Не работать с рисками.
Одна из самых недооцененных областей в проектном управлении – риски. Я видел ничтожное количество проектов, где менеджер и команда пытались управлять рисками. Именно эта область может сэкономить вам массу нервных клеток, и позволит менеджеру не поседеть раньше времени. Изучите риск-менеджмент (это не «rocket science», на всю теорию нужна пара вечеров) и применяйте его в своих проектах.
ОШИБКА №11.   Сдача-приемка методом большого взрыва.
Убеждение, что работу нужно показывать не когда «все сделано», а, когда есть первые понятные результаты и их еще легко подправить — появилось сотни лет назад. Сейчас оно красной нитью проходит сквозь любую методологию проектного или продуктового управления. Сделайте — покажите — спросите — поправьте.
Очень похожая штука составляет основу цикла Деминга (Plan — Do — Check — Act), являющегося основой, опять же, любого современного менеджерского подхода.
Почему же большинство менеджеров этого правила не придерживаются? Почему кто-то все еще считает, что лучшее место познакомить заказчика с результатами — финальные приемо-сдаточные испытания? Один мой коллега как-то сказал (работали вместе на ИТ-проекте для гос. сектора): «дуракам половину работы не показывают». В его словах на тот момент был резон. Но не дайте этому принципу одурачить вас.
Сдача-приемка всего и в последний момент («методом большого взрыва») — экстремальное и вредное для психики заказчика, менеджера и проектной команды развлечение.
ОШИБКА №12.   База знаний — «не для меня».
Чем хороший менеджер отличается от плохого? Если бы ответ допускал пару слов, я бы ответил: «базой знаний». Компания может не вести архивных записей или делать это неудачно (неудобно, неполно или напротив — с большим количеством мусора). Но никто не запретит вам фиксировать «усвоенные уроки» или результаты «ретроспектив» самостоятельно. Для себя. Со всем уважением к корпоративным практикам хранения конфиденциальной информации, конечно.
Но у вас должен быть свой «менеджерский чемоданчик», в котором не только удачные примеры списков рисков, чек-листов, графиков и бэк-логов, но также оформленные наблюдения и выводы, рекомендации самому себе в будущем. В прямом смысле, усвоенные уроки по отраслям, продуктам, или, например, по работе с распределенными командами. Думаете, ни за что не забудете ошибок или удачных решений? Даже не надейтесь.
Жизнь менеджера проектов — это буря. Запишите. Положите в виртуальный «чемодан», которым лично вам будет удобно пользоваться. И, который вы откроете при запуске очередного проекта.
ОШИБКА №13. Слишком уважать или слишком презирать методологии.
За более 20 лет практики в управлении проектами чего только не наслушались о вреде и пользе методологий. Сами относились к ним по-разному в первые пять лет (то читали, то бросали, то считали, что «они не годятся в моей стране-отрасли-компании-команде», то меняли мнение на противоположное). Скажем просто. Методологии управления проектами писались умными людьми. Очень умными.
Если вам кажется, там глупость — отложите. Перечитайте через два-три года. Ведущие методологии похожи, что говорит о том, что умные люди независимо друг от друга нашли одни и те же принципы, которые работают лучше всего. Отворачиваться от этих практик, пожалуй, безрассудно. Однако, почти любая методология — адаптируеется. Она предполагает, что вы возьмете ее за основу и «доработаете напильником» под свои реалии. Там не каждое слово священно. Не каждый шаг или инструмент — лично вам. Изучайте методологии. Экспериментируйте с ними. Дорабатывайте на свой вкус и обязательно проверяйте эффект. Это путь становления правильного менеджера.
********************
Какая-то ошибка не указана? Смело дополняйте в комментариях! Сколько людей — столько опыта. Любой опыт полезен.
Надеемся, что и этот опыт, опыт наших экспертов (этакий «взгляд со стороны») вам пригодится. И, если не даст конкретных рецептов, то покажет «слепые пятна», на которых глаз давно замылился, или же укажет на точки роста.
А через пару дней поговорим о том, как оценить собственный проект и его управляемость.
В любом случае — успехов вам и вашим проектам!