Много статей и советов о навыках, необходимых для успешного проекта, но практически всегда, особенно в спорте, мы слышим, что максимальный levelup дает нам — ПОРАЖЕНИЕ! Хочется поделиться своим «провалом» и как я действовал по обстоятельствам, а вы можете подумать — чтобы сделали вы.
Возможно кто-то более опытный или сообразительный сталкивался с таким и с ходу прокомментирует как можно было избежать каких либо из перечисленных проблем.
Я же самый самый обычный человек (2 руки 2 ноги), с небольшим тех бэкграундом и минимальным опытом управления проектами (1 год), и вообще даже не понимающий кто я и зачем в этом мире.
И еще, все ограничения (то есть условия заданные, но не описано их возникновение) априори считаются принятыми читателем. Рассматривайте это как задачу из учебника по шахматам, где расстановка фигур дана в задании и надо выиграть или свести к ничьей, а кто и почему бездарно «просадил» все остальные фигуры и загнал в угол оставшиеся неважно. Работаем с тем что есть.
1. Мы выбираем — нас выбирают
Как часто говорится, что сначала надо делать ТЗ. А еще лучше делать его не за бесплатно, а за деньги Заказчика.
Бойтесь желаний своих!
PM такая же назначаемая должность в проектах как и все остальные, поэтому вполне рабочая ситуация, что достается проект уже с ТЗ и ответственностью за его реализацию.
Так случилось и со мной, ТЗ есть (причем не просто там ТЗ, а набор спецификаций различных, все по полной программе), предварительные бюджет и сроки Заказчику озвучены (да, иногда вам просто «прилетает»).
Бегло смотрю что привалило (качество ТЗ) — все очень плохо, но пока я еще не осознаю масштаб катастрофы. Чутье мне подсказывает — беги Форест, беги! Но бежать некуда, не взять проект компания не может себе позволить (много причин). Что же делать? Ты же руководитель? — думай, в этом и есть твоя работа! И так оно и есть — невозможное возможно.
Решение
Принимается быстро из доступного сейчас «арсенала», сроки и бюджет «х2», а там видно будет)
Заказчик конечно мягко говоря в шоке, про сроки вообще не рад. Ладно, сроки делаем «x1.5», но бюджет оставляем «x2».
«Страховой агент должен уметь две вещи: сначала — напугать, а потом обнадежить.»
2. Люди — они не ресурсы!
Все всегда так классно и круто рассказывают про команды (чаще с картинками про 11 друзей Оушена), которые ВСЕ могут. Увы, но иногда «команда» на старте проекта — это доступные (иногда на безальтернативной основе) сотрудники компании с минимально подходящими знаниями и может быть даже не знающие друг друга. А чтобы было еще веселее, «ресурсы» добавляются в dream team — постепенно, по мере освобождения из других проектов.
Решение
Время жмет, команда распределенная, поэтому решение комплексное:
- Наплевав на все там планы по задачам, на входе в проект каждому дается 1-2 недели на погружение без задач в Jira.
- Показать текущее положение дел. То есть все показатели проекта должны быть на самом видном месте (стартовой странице проекта в Confluence), актуально обновляться и должно быть понимание откуда это все берется и зачем. Все должны понимать в какой мы Ж и как быстро погружаемся все глубже. Раньше это была моя внутренняя отчетность по проекту внутри компании перед руководством, но тут я изменил политику и направил отчетность по проекту обратно в команду.
- Нет митингам! Ход конем) Только одна планерка совместная по понедельникам для накидки новых ближайших задач или совместного решения по тем, что застряли. Концепт простой, если мы не будем контактировать самостоятельно друг с другом — у нас вообще нет шансов. Так зачем соблазнять людей митингами, до которого можно отложить обсуждение проблемы. Есть проблема — звоним сразу, заодно начинаем общаться друг с другом. А это уже и есть — проблески команды.
3. Утром стулья — вечером деньги!
Худший из кошмаров в проекте на мой взгляд — проблемы с зарплатой!
Все наверное знаю такой оборот как — кассовый разрыв. Но тут все хуже. Реальные проблемы. Перспективы вылезти из этого есть, но факт есть факт. Денег нет.
Решение
А тут может быть решение?
Не знаю, что тут вообще можно сделать. Собрались все. Все всё понимают. Попросил если есть возможность предупредить о своем уходе максимально заранее и что всё пойму, но у меня хоть будет время подумать «как дальше жить». Кого-то я знал лично, поэтому знал что они останутся. На остальных повлиять не мог.
В дальнейшем все исправилось, но не все дожили до светлых дней :(
4. Новые требования
Все мы знаем, что аппетит приходит во время еды. Поэтому новые требования в начале и середине проекта — это святое.
Решение
Буферов под это не закладывалось, поэтому сразу был обозначен только один путь — расширение объема и стоимости работ.
Но была фишка — если за Х дней новые работы не оплачиваются, то те же самые работы дорожают на Y% (озвучивалось постфактум — так как и идея эта пришла, когда стало понятно что ситуация имеет тенденцию к затягиванию). Это стимулировало сразу определяться с тем — пойдут эти работы или нет.
5. Деньги решают все
Одна из техник по управлению рисками подразумевает решение с помощью создания буферов. Но куда тратить эти «деньги» если время нельзя купить? Я честно до сих пор не знаю, как и где люди собирают свои команды, особенно в сжатые сроки.
Решение
Первую половину проекта я пытался найти кого-то на рынке и увеличить команду, но бесполезно, не было даже вариантов кого я готов позвать. Дальше введение новых людей только увеличило бы срок сдачи проекта, поэтому с этой идей было покончено.
Дальше буферы тратились на переработки тем кто был не против и откладывались на потом четко понимая, что в срок мы уже не завершим работы.
6. А судьи кто?
Классика аналитики говорит, что первым делом в начале работ определяются критерии необходимые для успешного завершения проекта: список фичей, что надо сделать чтобы сдать каждую из них, кто будет ее принимать, на каком оборудовании.
Но у нас есть сразу ТЗ (список требований) — и это была западня. Честно говоря иногда отсутствие ТЗ лучше чем его наличие.
Решение
Худшее из возможных решений. Делаем так как самим видится правильным. Если это противоречит ТЗ, значит нарушаем его.
7. Большой брат следит за тобой
Самая интересная часть моих проблем с самым классическим человеческим решением.
Я думаю у всех всегда есть какая-то внутренняя отчетность. В любой компании есть свои KPI или артефакты по которым судят о ситуации на проекте. Так как с самого начала на проекте было все плохо, я как мог старался это отражать это в отчетности. Но… ничего не происходило. Как я считал, помочь мне никто ни с чем не мог. Тогда к чему мне еще проблемы?
Решение
Я стал врать! Без каких бы то ни было угрызений совести. Я врал всем кому надо, если это мешало или отвлекало меня от проекта.
Но одним людям я не врал — команде. Я не врал им даже о том, что вру наверх о том, как у нас дела. Это было, наверное, опасно. Но я был частью команды — а самому себе врать нельзя.
8. Теперь нам нужно чудо или Soft skills
В каком-то комментарии тут на хабре я прочитал, что самая важная задача PM это — отмазаться от законных требований заказчика (фраза не точная, но суть передает). Так вот, эта магия мне пока не под силу. Но что-то мне подсказывает, что все проекты так или иначе отклоняются от первоначальных требований. Особенно если всплывают такие вещи как производительность или резкая смена «приемщика» работ.
Решение
Мои возможности были не безграничны. Решение юридических, технических и организационных проблем и так занимало кучу времени. Большую часть требований в ТЗ удалось изменить до корректных формулировок и согласовать. Но остались условия, которые так и не были выполнены. О чем я сообщил на сдаче работ. Я не видел смысла сообщать об этом раньше, так как сдаче проекта в срок это ни как не могло помочь.
P.S.
Я специально не давал оценку результату моих решений, так как все равно это будет субъективно.
Объективная картина — срок и объем проекта не выполнены, часть команды потеряна.
Есть только одна поправка, в целях проекта не было — создать команду.
Вот история некоторых моих проблем при управлении самым обычным проектом.
«Все события и персонажи вымышлены, любые совпадения случайны».
Автор: b00b1ik
