Но без плана же никак нельзя
Давно, году эдак в 2011, я работал в команде, запускавшей вторую версию Единого Портала Государственных услуг, прозванной за дизайн «Стекляшкой». Это был первый профессиональный опыт разработки программного обеспечения для меня. И он был очень горячий 🔥 Особенно у нас сильно горели сроки, потому как часто водится с государевыми заказами - там был жестко зафиксирован дедлайн.
И вот, получил я чудную задачу актуализировать план внедрения. И очень удивлялся тому, что у нас осталась условно неделя до дедлайна, задач нерешенных куча, вся команда из нескольких десятков человек ночует в офисе, а тут просят потратить время на актуализацию плана, что в тот момент мне казалось абсолютно непозволительной роскошью. Да и задач, которые казалось правильным вписать в план было сильно больше, чем оставшихся дней. 🤯
Я попробовал высказать свои возражения, но менеджер проекта со стороны проектного офиса заказчика тогда сказал фразу, мудрость которой я со временем только до конца понял: «Но без плана никак нельзя»!
А планов за эти годы было нарисовано несметное множество. 🙃 Вот что я понял в этой деятельности для себя:
🗺️ План нужен тебе как лидеру деятельности
Понимание граничных условий и структуры работы, которую надо сделать, дает возможность что-то в ней оптимизировать почти всегда.
Также, план позволяет не забыть что-то по случайности, или, что хуже, по ложному убеждению, что какая-то часть работы не твоя («смежник отвечает»). За все в твоем плане отвечаешь только ты, даже если сам эту работу и не делаешь.
Наличие дедлайна в плане почти никогда не означает, что работа закончится до него. 🤷🏻♂️ Потому твой рассказ о движении по плану и причинах сдвигов, сыгравших рисках и новых «потерянных» задачах позволит модераторам твоей деятельности осознать твою степень нацеленности на результат и принять решение оставить тебя у руля некоторой активности.
🤷🏻♂️ Чужим планом люди интересуются слабо
Твой руководитель или заказчик редко читает подробности плана: он смотрит на граничные даты и вехи, смотрит на количество рисков и красных флажков, и что самое главное, на то, что и как ты говоришь, рассказывая о движении по своему плану.
Твои смежники или сотрудники план могут смотреть, могут активно декларировать желание быть в него посвященным, но по опыту они больше пытаются понять, что и когда тебе от них надо. Когда все закончится в комплексе, это уже не их головная боль. Такова жизнь.
Потому, если план просто прислать на ознакомление, но не прийти и проговорить в явном виде с ключевыми исполнителями, кто в нем участвует, то шансы на провал радикально повышаются.
😌Не надо усложнять план
Люди могут декларировать желание получить максимально детальный план от лидера. Например, меня так однажды пытались склонить к «лучшей» практике: в плане должно быть минимум тысяча строк и нам регулярно (ежедневно) надо его обновлять.
Это не попытка помочь достижению результата, а маскировка того, что на самом деле твое видение плана вообще не поняли. И еще попытка повысить осознание значимости ответственности за твой план. Ведь план - это всегда коммитмент.
Сложные планы требуют излишне много времени на свою поддержку, что абсолютно не оправдано в обычной разработке ПО. Возможно, это было бы целесообразно при запуске ракеты в космос, но и то не уверен.
Сейчас планы вместо тяжеловесных структур Microsoft Project почти повсеместно реализуют в виде слайдов с дорожной картой в обыкновенной презентации.
Этот формат больше направлен не на контроль всех шагов плана, а на обсуждение развилок по запросу владельца плана. Это презентационный материал, получается.
По нему люди вокруг видят степень веры владельца плана в достижение цели в определенном временном отрезке.
💪🏼 И, напоследок, самое главное - план меняется, это живой инструмент, который надо взять на себя смелость обновлять при изменении обстановки.