планирование | Владимир Бычко об управлении проектами

Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Тег: планирование

Вовремя и в рамках бюджета

Изображение с unsplash.com

Вовремя и в рамках бюджета. А так вообще, бывает? У меня было ровно один раз. Руководство попросило сделать индивидуальную доработку (кастомный отчёт на Microsoft Reporting Service) прям образцово, чтобы можно было показывать коллегам как пример. Отчего же не сделать? Какими принципами я руководствовался, чтобы это сделать? Какие ходы провёл?

Принцип простой — надо сначала сделать хорошо, а потом искать закономерности. Если сначала написать правила, а потом по ним пытаться создать что-либо, мы получим рабочую модель Прокрустова ложа.

Артемий Лебедев, дизайнер.

Артемий Лебедев

Ководство, § 178

Менеджер давно в компании. Я тогда работал третий год и детально разбирался, к кому с каким вопросом идти. Это прям основа, без этого ничего не выйдет.

Первичная оценка (пресейл). На входе даём заказчику только порядок цифр, чтобы он принял решение, влезает ли доработка в его бюджет. Тратим на эту оценку буквально три часа. Час созвониться с заказчиком, час подумать и поговорить с разрабом, час оформить. Заказчик на выходе получает небольшую табличку с разбиением трудозатрат по статьям. И всё.

Только после того, как заказчик принял первичную оценку и сказал «делаем», приступил к точной оценке. Или фазе планирования. Оценивают те, кто будут делать. Я сам выступаю в роли аналитика, разработчиком будет опытный чувак, который ранее делал такие вещи. Он же делал первичную.

Сбор требований. Созваниваюсь с заказчиком, выясняю бизнес-проблему, чего он хочет добиться этим отчётом, почему именно на RS. Разбираемся с входными параметрами, показателями, агрегацией итогов.

Прототипирование. Открываю Excel и прям рисую отчёт, максимально приближённый к реальности. Показываю разработчику, он указывает на вещи, которые будет невозможно или трудно реализовать. Ещё несколько раундов созвонов, расспрашиваю разные детали про отчёт.

Написание ТЗ. Максимально аккуратно, «сверху вниз» фиксирую всё собранное в ТЗ. Согласую ТЗ с заказчиком. Увидев ТЗ они добавляют ещё хотелок. Обсуждаю их с разработчиком, вношу в ТЗ. Это был самый длительный этап. Из-за того, что заказчик не спешил, мы созванивались пару раз в неделю по часу-полтора и не спеша формировали ТЗ. Этап вышел месяца полтора.

Точная оценка. Вместе с разработчиком пилим ТЗ на таски, оцениваем эти таски. Получаем чистую оценку разработки. Применяю корпоративные «волшебные формулы», по которым рассчитываю оценку тестирования, накидываю другие накладные затраты. Накидываю время, которое ранее потратил на прототипирование, требования и ТЗ.

Работа с рисками. Накидываю к оценке дополнительные часы на возможные технические трудности (по минимуму, задача понятная), затем на возможные дополнительные хотелки заказчика, которые вылезут в ходе приёмки, чтобы не пришлось пересогласовывать оценку (уже побольше).

Формирую итоговое ТЗ и точную оценку, засылаю заказчику. И только после того, как заказчик мне отвечает на имейл, что согласен, мы рассчитываем сроки с учётом реальной загрузки разработчика.

На этом основная часть работы пиэма-аналитика заканчивается. Нужно мониторить и контролить разработчика в процессе кодирования. Я также провёл приёмочное тестирование, мы немного подправили макет. Отдали в полноценное тестирование тестерам, они пошатали отчёт, нашли ошибки, мы их поправили.

Приёмка. Провели демонстрацию отчёта заказчику. Получили замечания и парочку новых идей, но так как несколькими шагами ранее заложили такие риски, пересогласовывать оценку не пришлось. Доделали, накатили на контуры заказчика.

Паровоз паззл.

Разработчик написал пояснительную записку о деталях функционирования отчёта, а я пользовательскую инструкцию. Штатный техпис отрецензировал и навёл на эти документы красоту.

Провели мини-ретроспективу, оценили с командой сложность доработки, определили размер премии, полагающейся разработчику (мне премий не платили, у тестеров своя система мотивации).

Вовремя, с затратами в рамках бюджета. Близко к идеалу. Правда, работает только на небольших проектах. Потом количественные изменения превращаются в качественные, тогда на первое место выходит метод набегающей волны.

К сожалению, в большинстве проектов так не получается. В некоторых компаниях пытаются подменять фазу планирования пресейлом и выкатывать очень точную оценку с дизайном команды и сроками на этапе пресейла. В других забивают на риски, делая оценку вплотную, чтобы смета вышла не слишком дорогой. В третьих проект делает команда людей, устроившихся в компанию две недели назад.

Пока журавли говорят, синицы делают.

Как ставить задачи так, чтобы подчинённые их выполняли

Изображение с unsplash.com, автор Luis Villasmil

Как у начинающих, так и у опытных руководителей бывает проблема. Они, вроде, грамотно ставят задачи подчинённым, но те всё время их факапят. То забудут что-то сделать, то сделают, но не так. Приходится буквально стоять у них над душой, тратя на этот микроменеджмент много времени.

Если немного изменить свою манеру постановки задач, с проблемой справиться можно. Крайне безответственных людей не так уж много, основную массу подчинённых вполне реально натренировать выполнять всё качественно и в срок. Полетели.

Увеличить трудоёмкость постановки задач

Нужно уделять больше времени постановке задач. Между тем, как много времени и внимания вы уделяете постановке задачи и тем, насколько качественно её выполнят, есть прямая связь. У руководителя часто нет времени на нормальную постановку, поэтому он просто небрежно бросает задачу в подчинённого, надеясь, что тот сам разберётся. Не уточняет, какие предпосылки у задачи, кто заинтересован в результате, почему она важна. Зачастую даже забывает сказать, к какому сроку её нужно выполнить. Руководителю кажется, что он такой халтурной постановкой экономит время, но на самом деле, он только добавляет себе работы в будущем.

Если ставите задачу, делайте это качественно, тратьте на это время, добивайтесь от подчинённого реального понимания задачи.

Убедиться, что сотрудник, действительно, понял задачу

Тут всё более-менее просто. Попросите сотрудника своими словами пересказать, что именно вы от него хотите. На этом этапе можно легко и дёшево отсечь всякие когнитивные искажения и ошибки восприятия.

Если задача объёмная, попросите сотрудника быстренько накидать список шагов, которые он предпримет для выполнения. Это тоже отличная практика. Тут есть ещё один скрытый плюс — люди с большей охотой выполняют задачи, которые спланировали самостоятельно.

Ставить задачи письменно

Однажды мне довелось работать на чувака, который говорил, что даже если он просто вскользь бросил какую-то мысль, я должен это воспринимать как задачу. Это совершенно кошмарный подход. Большинство сотрудников нормально так загружены, у них и так очередь задач. Если вы такого человека попросите сделать что-то устно, он сделает это, только если сам имеет привычку записывать все задачи. В остальных случаях он просто о ней забудет.

Не дайте сотруднику такую возможность. Все задачи ставьте только письменно, лучше в каком-нибудь таск-трекере на свой вкус. Тогда забыть о такой задаче у подчинённого не получится. Кроме того, эта мера усиливает самую первую инструкцию из этой статьи — ставя задачу письменно, вы структурируете собственное мышление и делаете постановку более качественно. Если таск-трекера по какой-то причине нет, напишите хотя бы имейл.

В целом, обсуждать задачи устно норм. Но в письменной форме задача обязательно должна присутствовать. Устное общение только подкрепляет задачу.

Напоминать и требовать

Вообще, напоминаниями должен заниматься таск-трекер. Но если задача действительно важная и вы лично напомните сотруднику о том, что её нужно делать, эффект будет больше и сильнее. Помните о том, что существует начальный, промежуточный и конечный контроль. В этой части статьи речь о промежуточном. Если поставили задачу подготовить документ к концу недели, обязательно в среду напомните.

Необходимость напоминать и требовать часто вызывает у руководителей психологическое сопротивление. Но его нужно преодолеть и напоминать не забывать. Это часть работы руководителя и пока всех работников не заменили нейросети, ей придётся заниматься.

Если вы будете доброжелательно, но настойчиво напоминать о задачах, у подчинённых постепенно выработается правильное отношение к вашим задачам и они будут выполнять их более дисциплинированно. Сотрудники поймут, что им проще выполнить задачу, чем продолбать, вы всё равно, не забудете и не слезете.

Благодарить за выполнение задач

Это неочевидно. Вам кажется, что зарплаты (зачастую весьма неплохой) вполне достаточно в качестве благодарности за выполнение задач. Это не так. Люди не роботы, у них есть мотивация. Когда вы благодарите человека за выполненную задачу, вы тем самым ему даёте понять, что то, что он делает, правильно и несёт пользу организации, а это очень сильно влияет на мотивацию.

Кроме того, сотрудник, когда его благодарят за качественно выполненные задачи, сам начинает стараться делать это почаще. Так что, пусть в вашем лексиконе поселятся слова: «спасибо», «благодарю», «молодец», ну или хотя бы большой палец или огонёк в телеграме, если у вас слова платные и вы их экономите.

В целом, применение этих пяти простых методов очень сильно повысит дисциплину ваших подчинённых, а значит и успешность бизнеса.

Как совершенно точно не стать профессиональным руководителем

Изображение с unsplash.com, автор Austin Distel

Ранее я писал, как совершенно точно не получить повышение на работе. Сегодня хотел бы рассказать, как гарантированно не стать профессиональным руководителем и навечно остаться «управляющим бровями».

Пост навеяла двухнедельная работа на айти-подразделение ГК «Самолёт» в начале этого года. Там мне попытались передать команду, которой ранее руководила девушка, пришедшая в айти из юриспруденции и организовавшая работу так, как умела — то есть, замкнула на себя всё. От детальной координации каждого исполнителя до анализа продуктовых и проектных метрик, кадровых вопросов и разбора обращений из соседних подразделений (за две недели я их наловил сорок восемь). В сочетании с очень тревожным руководством, требующим ежедневной отчётности и постоянными совещаниями, каждый час, каждую минуту, это показалось мне одним из самых больших управленческих кошмаров. Такое подразделение можно перестроить, с руководством выстроить правильные отношения, но на это уйдёт неимоверное количество нервов и времени, которых у меня нет.

Поэтому рассказываю в этой статье вредные советы, как довести подразделение до состояния полного ручного управления.

Но перед этим прочтите, пожалуйста, пост Дениса Сиденко про «управление бровями» (Линкадин под блокировкой, чтобы блок отобразился, поставьте какой-нибудь плагин с автоматическими прокси или врубите vpn):

Для того, чтобы точно не стать профессиональным руководителем, нужно делать пять вещей. Давайте разбираться, какие именно.

Хочешь сделать хорошо — сделай сам.

Лучшего программиста делают тимлидом. Лучшего продавца — РОПом. Лучшего дизайнера — арт-директором.

Одновременно с этим Лебедев убедительно попросил меня не рисовать больше ничего и дать дорогу молодым: инструмент арт-директора — дизайнеры, а не рисовальная программа. Я тогда получал в день пять десятков писем и ничего совершенно не успевал, хоть вешайся.

Людвиг Быстроновский

Людвиг Быстроновский

арт-директор Студии Лебедева

Естественно, у вчерашнего исполнителя постоянно возникает желание «закатать рукава» и показать этим щенкам, как правильно писать код, заключать сделки, дизайнить дизайн. Руководитель постоянно закатывает рукава, ему постоянно аплодируют и хвалят, какой он молодец, у него отличная самооценка, только в отделе бардак и невыстроенные процессы, на менеджмент времени совершенно не хватает, расти отдел категорически не может.

Есть хорошее мысленное упражнение. Начать управлять так, как будто вам оторвало руки. То есть, вы можете ставить задачи голосом и письменно, но не можете сами ничего делать. Обучать (об этом ниже), мотивировать, координировать можно.

Людвиг, цитату которого я привёл выше, сделал первый шаг, поменяв ноутбук. Продал семнадцатидюймовый гроб, на экране которого помещался журнальный разворот в натуральную величину и купил маленький изящный ноут. Тоже полезное действие.

Невозможно быть руководителем на 80 %. Вы либо управляете, либо исполняете. А кроме того, невозможно управлять системой, будучи её частью.

Не обучать

Обучать трудно и страшно. Трудно, потому что умственно тяжело систематизировать собственные, часто хаотичные знания. Да и некогда, потому что см. предыдущий раздел. Страшно, потому что у выучившегося сотрудника вырастут зарплатные запросы, он может уволиться или вас подсидеть. Поэтому он никого никогда не обучает и не отправляет на обучение. Только вот увы, отдел опять не растёт. И любая проблема, которая будет прилетать в ваше подразделение, будет решаться только вашими руками.

Да и в конце концов, вас же никто ничему не учил, вы всё сами постигли, правильно? Чем они лучше?

Рост зарплатных аппетитов — это нормально. И это ваша забота, время от времени наведываться к вышестоящему начальству и убеждать, что фонд оплаты труда не должен быть ниже фонда рекрутинга.

Периодические увольнения — это тоже нормально. Люди будут увольняться, это не просто риск, это стопроцентный факт. Вы обязаны выстраивать систему так, чтобы от увольнения сотрудника, даже очень важного и квалифицированного, система не рушилась. Дублирование функций во все поля.

Что касается подсиживания. Если ваш топ-менеджер или гендиректор или кому вы там подчиняетесь, такое допускает, это к лучшему, работать на него не надо.

На деле обучение сотрудников сильно повышает их мотивацию и минимизирует выгорание, отчего результаты отдела растут.

Давать распоряжения и инструкции только устно

Ещё один страх новоиспечённого руководителя — что каждый сотрудник будет понимать, что ему делать и руководитель из-за этого станет ненужным. Поэтому он старается вообще, избегать письменных распоряжений и инструкций, налегая на «управление бровями». В целом, система работает, руководитель незаменим, к нему постоянно обращаются с вопросами, он чувствует себя важным и востребованным. Только вот времени больше ни на что не хватает, особенно с учётом пункта про хочешь сделать хорошо — сделай сам. А вам ещё и придётся рассказывать, как делать ту или иную работу довольно часто.

У меня был руководитель, который любил говорить, что даже если он озвучил невпопад какую-то мысль, я должен её воспринимать как поставленную задачу и ломиться исполнять. Мысль о тикет-системе (я тогда был сисадмином) его пугала так, что он даже рассматривать её не хотел.

Каждая повторяющаяся работа должна быть регламентирована, а ещё лучше, автоматизирована. Это позволяет значительно быстрее погружать в контекст новых сотрудников и освобождать свой мозг для работы более интеллектуальной, чем в сотый раз объяснять сотому по счёту офис-менеджеру, как правильно печатать на конвертах. Короче, читайте статью про регламенты.

Да, тут есть другая крайность. Можно дорегламентироваться до многостраничных мануалов, которые будет трудно воспринимать (как, например, в айти-подразделениях «Комуса»). Но в целом, и это лечится, просто не требуйте от новичков знания их наизусть, пусть ознакомятся и разок на практике их пройдут и всё получится. Читайте правило про обучение.

Не давать сколько-нибудь детальных планов

Ещё один страх руководителя — что если его подчинённые будут посвящены во все планы, он опять станет ненужным. Да и не требуется от них это знать, вдруг ещё сольют конкурентам. Лучше не планировать вообще, ведь если плана нет, его невозможно провалить. Но да, при росте количества подчинённых, придётся слишком много двигать фигуры, но вы же не боитесь лишней работы.

Каждый солдат должен знать свой манёвр.

План операционный в корпус, в колонну. Ясное распределение полков. Везде расчет времени. В переписке между начальниками войск следует излагать дело ясно и кратко, в виде записок, без больших титулов. Будущие же предприятия определять вперед на сутки или на двое.

Александр Суворов.

Александр Васильевич Суворов

русский полководец

Сотрудникам несвязанных отделов знать детали планов друг друга, действительно, большой нужды нет, но они должны, во-первых, знать стратегические цели всей организации, а во-вторых, планы свои.

Только тогда они смогут работать более-менее самостоятельно, плюс, не придётся постоянно давать им приоритеты. Ведь если все знают, что важно для компании, а что не очень, приоритеты становятся понятны сами собой.

Слепой лось, бегущий через горящий лес.
Мемас из сети.

Кроме того, зная верхнеуровневые планы подразделения, сотрудники смогут ставить себе личные планы самостоятельно, оставляя руководителю возможность их ревьюить и корректировать.

У меня был такой кейс. Раз в месяц я готовил список ключевых манипуляций по проекту на следующий месяц. Закончить такой-то блок работ, завершить тестирование такого-то блока, провести ревью требований, автоматизировать то-то. Потом находил время в расписании своего босса, мы запирались в кабинете, садились рядом и совместно этот план вычитывали, попутно проставляя, какое влияние исполнение каждого пункта будет оказывать на мой бонус в конце месяца. Босс задавал вопросы, иногда добавлял свои пункты, иногда вносил коррективы. Потом я этот план доносил до сотрудников и каждый понимал, чем ему в этом месяце заниматься. Хорошая практика.

Не координировать людей

Это не страх, это скорее, популярное заблуждение, что лучшая организация работ — как на советском заводе. Не то, что в одном цеху не знают, что делают в другом, не то, что за одном столом не знают, что делают за соседним, люди сами не до конца понимают, что делают.

Важная для недоменеджера особенность отсутствия координации — в случае неудач будет очень легко найти виноватых.

Понимание того, что вы делаете важную и востребованную работу, очень важно, оно уменьшает выгорание и повышает производительность.

Иногда приходится делать работу, которая важна, но у результатов которой не будет внятных потребителей. Про неё читайте в моём посте про корабль конвоя:

В принципе, если у вас небольшая команда людей, сидящих по заветам идеологов скрама в одном помещении, большой необходимости в координации нет, они и так прекрасно знают, кто и чем занимается. Но если у вас большое распределённое подразделение, без координационных встреч никак.

Если команда большая, лидам направлений имеет смысл собираться каждый день со своими сотрудниками, координироваться. Как часто нужно собираться лидам и вам — вам решать, но время от времени надо, чтобы послушать их новости и рассказать им свои.

Если так получилось, что под вашим контролем несколько подразделений, собирать их на координацию целиком, конечно, не надо, но встречаться, хотя бы раз в пару недель, с их руководителями необходимо.

Что менеджеру проектов нужно знать об ИСР

Изображение с диска «Реклама и коллаж», автор Lynn Stephenson

Несмотря на то, что проектами можно считать и простенькие активности, состоящие из трёх-четырёх работ, в реальных проектах их обычно сильно больше. Даже для простенького мобильного приложения можно выделить до сотни конечных работ. Для их представления нужна ИСР, иерархическая структура работ или, по-английски, WBS, work breakdown structure. В этой статье подробно разберём все аспекты подготовки этого проектного артефакта.

В целом, всё просто. Проект разбивается на отдельные работы до тех пор, пока не получатся атомарные задачи. Насколько мелкими должны быть конечные задачи? В каждой компании свой подход к этому. Кто-то требует, чтобы задача умещалась в 8 часов. Кому-то достаточно, чтобы задачу мог выполнить один сотрудник.

Вы можете создавать ИСР и для личных дел, включающих много аспектов. Вот, например, ИСР, которую я составил, когда переезжал на новую квартиру:

Я использовал Minjet MindManager для составления этой карты. Так удалось не упустить ни одного аспекта переезда. Значком мигалки помечены крайне важные работы, но можно использовать и более продвинутую приоритизацию.

Что же касается «взрослых» проектов, термин был впервые употреблён в 1993 году в США.

Теория

Графическое представление ИСР выглядит нагляднее, чем обычный список, благодаря возможности сворачивать и разворачивать узлы структуры.

ИСР позволяет более правильно организовывать работу над проектом, даёт представление об объёме работ, повышает прозрачность управления. Команда, имеющая доступ к ИСР, лучше понимает, как решение каждой из задач поможет достичь проектных целей.

Декомпозиция работ в дальнейшем сильно облегчит вам планирование, оценку загруженности команды, распределение задач между исполнителями. Добавив туда информацию о плановых трудозатратах, вы сможете верно оценить сроки. Имея ИСР перед глазами, вы сможете эффективней выделить ключевые риски и посчитать стоимость проекта. Вам станет понятно, на какие этапы вам хватает имеющихся сотрудников, а для каких нужны дополнительные силы.

Также ИСР позволит выявить связи между работами.

Обычно её создают во время инициации и уточняют в процессе планирования. После вам лишь останется держать её в актуальном состоянии.

Важные принципы составления ИСР

Иерархическая структура работ проекта строится на следующих принципах:

  • Включать только работы, реально значимые для достижения целей проекта. Посторонние задачи не включать.
  • Не дублировать задачи и не детализировать слишком уж сильно.
  • У каждого дочернего пункта только один родительский.
  • Детализировать до работ, которые может выполнить один исполнитель. Не допускать пунктов, для исполнения которых нужно несколько сотрудников.
  • Самые верхнеуровневые работы должны быть достаточно автономными.
  • Каждый пункт следует снабдить ссылкой на требования, но это можно сделать и позже, в процессе подготовки требований.
  • Избегать глаголов, больше существительных.

Алгоритм создания ИСР

Можно создавать ИСР в одно лицо, но я обычно привлекаю аналитика на начальных этапах и лидов компонентов (фронт, бэк) на более поздних (для нормальной декомпозиции). В целом же, порядок таков:

  1. Идентифицировать конечную цель проекта, по идее, это должен быть некий уникальный продукт. И разместить эту цель в корне иерархии.
  2. То, что мы сделали на предыдущем этапе, декомпозировать на понятные и достижимые компоненты первого уровня. И разместить их на первом уровне.
  3. По тому же принципу сформировать второй, третий уровень. Четвёртый — это уже многовато, если вы задумались о четвёртом уровне, может быть, стоит разбить проект на подпроекты?
  4. Назначить ответственных за каждую работу.
  5. Готово, вы восхитительны ♥️

Крайне важно, чтобы работы были смартовыми.

Крайне важно сделать систему кодировок работ. 1 для корня, 1.1 для первого уровня, 1.1.1 для второго и так далее.

Формы представления ИСР

Если это (требования, отчёт, план) не помещается на одной странице – никто этого не поймёт.

Марк Ардис

Stevens Institute of Technology

Очень важно, чтобы ИСР удобно и читабельно отображалась. Мне известны следующие форматы представления:

  • Контурная структура. Просто список с уровнями. Самая простая в разработке и самая неудобная для просмотра структура.
  • Иерархическая таблица. Делается в экселе или гуглодоках. В первом столбце корень, во втором — первый уровень, во втором — второй. Когда уровни заканчиваются, в таблицу можно занести ответственных оценку и всё, что пожелаете. Тоже относительно просто делается, в использовании немного удобнее предыдущего варианта.
  • Древовидная структура. Делается в программах для деловой графики, Visio для обладателей компа на винде, Draw.io для всех остальных. Или можно использовать софт для майндмапов. Графически представляем все уровни, появляется возможность сворачивать и разворачивать узлы. Это уже совсем удобная штуковина.
  • Диаграмма Ганта. Это следующий этап работы. ИСР с проставленными ответственными, связями, оценкой сроков. Обычно делается в Microsoft Project. Я когда-то делал в Merlin Project.

В целом, это всё, что пиэму нужно знать об ИСР.

Написание требований методом набегающей волны

Аджайл аджайлом, но переставать требовать писать требования заказчики не собираются. И если от вас требуют реализовать большой кусок функциональности, лучше всего работает метод набегающей волны.

Суть проста. Во всех мифологиях, всех религиях, сколько найти, и в основе любой истории лежит один и тот же мотив. Разбиваете кусок функциональности на блоки. Например:

  1. Хливкие шорьки
  2. Хрюкотающие зелюки
  3. Мюмзики в мове
  4. Бармаглота сын
  5. Злопастный Брандашмыг

Затем упорядочиваете список по приоритету. В заказной разработке приоритеты можете спросить у заказчика, в продуктовой используете какие-нибудь приоритизационные фреймворки.

У вас должно быть общее понимание, что нужно делать в рамках каждого пункта, но без деталей.

Затем либо сами, либо с помощью аналитика пишете детальные требования для первого пункта списка, согласуете их с заказчиком и отдаёте в разработку.

После того, как первый пункт будет реализован, презентуете его заказчику.

После приёмки первого пункта, снова с заказчиком проходитесь по списку. 100 % вероятность, что либо поменяются приоритеты, либо некоторые пункты отвалятся, либо изменится концепция отдельных пунктов, а скорее всего, всё и с разу. Может быть, остальные пункты просто отвалятся, у меня был и такой случай.

И только после этого вы садитесь расписывать требования ко второму пункту или пункту, ставшему вторым. Этот подход здорово экономит время на анализ и проектирование, минимизируя объём требований, выкинутых в мусорку.

Изображение с videoinfographica.com

Задача-гамак

Вы наверняка замечали, что в программах для рисования календарных планов есть несколько видов связей, хотя почти всегда используется End-to-Start. Да, в правильно спланированных проектах таких связей должно быть большинство.

Также должен сказать, что существует четыре вида задач:

  • Атомарная задача
  • Агрегационная задача
  • Веха
  • Гамак

С первыми тремя всё более-менее ясно. Стандартная задача, штучка, которая агрегирует группу задач, задача с нулевой длительностью для формирования роадмапа. А вот про гамак я узнал на курсах несколько дней назад и хотел бы поделиться с вами.

Вот четыре задачи, связанные End-to-Start, в рамках которых проводятся некие работы:

А теперь представьте, что существует работа, которая должна проводиться всё время, пока проводятся задачи 2 и 3. Например, если в рамках этих задач проводятся работы по проведению публичного мероприятия, нам нужно дополнительной задачей обеспечить охрану и эта охрана должна работать ровно столько, сколько продолжаются мероприятия. Эту работу обязательно нужно включить в план, так как она требует трудовых ресурсов (время охранников).

Это делается так:

Задача-гамак

Задача 2 соединяется с задачей-гамаком связью Start-to-Start, задача 3 — связью End-to-End. Главное — не забудьте стереть у задачи-гамака оценку, иначе она будет отображаться неправильно.

Вот для таких случаев разработчики прожектовского софта и запасли для нас экзотические типы связей. Для скриншотов использовал Merlin Project.

Основные методы оценки сроков и трудозатрат

Эта статья может быть полезна начинающим PM-ам.

Снизу вверх

Я применяю этот метод чаще других. Он сводится к тому, что ТЗ декомпозируется до атомарных (или не очень атомарных, но относительно мелких) задач и каждая из этих задач оценивается. Затем оценки суммируются и мы получаем достаточно точную калькуляцию.

Недостатки метода в том, что он не работает, когда нет чёткого ТЗ и в том, что он относительно медленный.

Сверху вниз

Этот метод мной применяется чуть реже. Он работает, когда бюджет уже известен. Заказчик, к примеру, готов выделить на проект от 2 до 2,5 миллионов рублей и не более полугода срока. И тут уже исходя из этой суммы нужно определить доли, сколько каким специалистам уйдёт и какие работы мы в рамках данного бюжета можем сделать.

Главная проблема этого метода в том, что бюджета, скорее всего, не хватит, чтобы сделать работы нормально, а сроки чересчур короткие. Придётся резать качество, искать более дешёвых специалистов, придумывать разные оптимизации.

Оценка по аналогам

Подходит, если нужно оценить что-то, с чем ранее вы уже сталкивались. Да, каждый проект уникален, но внутри разных проектов могут быть куски, очень сильно похожие на аналогичные в других проектах.

Например, вы часто делаете вёрстку одностраничников и примерно представляете, сколько времени займёт простая или средней сложности вёрстка (сложную лучше так не оценивать). Для очень приблизительной, первичной оценки вполне сойдёт.

Параметрическая оценка

Усложнённый вариант оценки по аналогам. Например, если мы говорим о вёрстке, вы можете по опыту предыдущих проектов понять, что, например, блок обратной связи ваш верстальщик делает за 3 часа, а классический слайдер с кружочками и стрелками по бокам — за 4 часа. Таким образом, можно рассчитать стоимость достаточно быстро и точнее, чем при оценке по аналогам.

Чаще всего параметрическая оценка применяется не в айти, а в ремонтно-строительном деле или бытовых услугах. Например, компания может заявить стоимость мытья полов в квартире, равной 50 рублей за квадратный метр и делать оценку, исходя из количества квадратных метров.

Анализ предложений

Этот метод предполагает отправку на виртуальный рынок и запрашивание предложений. Хорошо работает, если вы заказчик. Формируем ТЗ, засылаем десятку аутсорсных контор, анализируем сметы, которые они пришлют.

Недостаток метода в том, что предложения могут различаться на порядок и никакого вывода из этой оценки вы сделать не сможете. Ну и применим он, когда вы заказчик или генеральный подрядчик, если вы конечный исполнитель, запрашивать предложения будет не у кого.

Экспертная оценка

Зовём внешнего или внутренного эксперта с большим опытом и просим оценить. На первый взгляд, здраво, но на самом деле, делать проект будет не этот эксперт и реальные цифры могут довольно сильно от этой оценки отклониться, особенно если ваша компания грешит выделением на ключевые участки работ джунов.

Ну и важный момент напоследок. Всегда, во всех случаях, на всех проектах обязательно проводите сверку итоговых фактических затрат с плановыми, чтобы сделать вывод о качестве оценки выводы и принять меры по её уточнению на следующих проектах.

Делегирование

Делегирование

Делегирует каждый руководитель, уже в силу профессии. И многие совершают две типичные ошибки.

Первая ошибка — поручить подчинённому задачу, а потом оценивать по тому, как справился бы с ней сам. Однако это в корне неправильно, вы ведь потратили на свою подготовку намного больше времени, чем ваш условный подчинённый.

Сравнивать качество выполнения задачи подчинённым можно только с тем, с каким качеством он выполнил задачу в прошлый раз — лучше, хуже, так же.
 
 
 
Вторая ошибка — путать ошибку и нарушение. Ошибка подчинённого есть там, где нет чёткого регламента действий. Он ошибся не по злому умыслу, а только потому, что не знал, как правильно поступить. Если сложилась такая ситуация, ругать человека не следует, а нужно этот участок регламентировать. А вот если подчинённый ошибается раз за разом на регламентированном участке (например, в правилах сказано, что приходить нужно в десять, а он неоднократно пришёл в офис к одиннадцати. Я вообще, против офисов, этот кейс приведён для примера), это уже звоночек. Тут стоит поругаться, оштрафовать или избавиться от нерадивого сотрудника.

Ошибся на нерегламентированном участке — регламентируем. Ошибся там, где есть чётко прописанные правила — наказываем.

Большие доработки

Большая работа — большие риски

— Как съесть слона, используя только нож и вилку?
— По кусочку.

Проведение больших доработок качественно отличается от мелких. Заказчик хочет здоровенный и очень сложный кусок функционала (будем называть его продуктом). Как не облажаться?

Если собрать требования ко всему продукту, сформулировать техзадание, потратить массу времени на реализацию, при сдаче выяснится, что заказчик хотел совершенно не это и нужно потратить ещё столько же времени на переделку. Разработчик и аналитик теряют впустую много времени, очевидный риск.

Если собрать требования ко всему продукту, сформулировать техзадание, разбить функционал на законченные куски, относительно быстро сделать и сдать первый, при сдаче выяснится, что требования к остальным кускам продукта существенно меняются. Это нормально — заказчик, увидев фрагмент продукта сразу начинает воспринимать его совсем иначе по сравнению с тем, что ранее было у него лишь в голове. Аналитик потратил впустую много времени, очевидный риск.
 
 
Избежать этих ключевых ошибок возможно, если использовать при написании требований вариацию на тему «метода прогрессивного джипега».

Давайте разберём контрольный пример.

Бизнес-проблема: «Для того, чтобы более эффективно продвигать и продавать наш товар (одуванчиковый лимонад), мы хотим онлайн-каталог».

Результат предварительного сбора требований:

На сайте должны быть разделы:

  1. Главная страница
  2. О компании
  3. Каталог
  4. Оплата и доставка
  5. Контакты

Ключевой момент — заказчику не понадобится оформление заказа с сайта. Только онлайн-каталог и форма отправки заявки.
 
 
Хорошо. Составляем крупноуровневый план работ:

  1. Разработать и согласовать концепт дизайна контентных страниц.
  2. Изготовить Главную страницу.
  3. Изготовить Каталог.
  4. Изготовить прочие контентные страницы.

 
 
В ходе первой итерации мы будем делать концепт дизайна, а затем — Главную страницу.

Ключевой момент — на первом этапе детализируем только требования к дизайну и главной странице. Остальные пункты плана для нас как бы в тумане. Мы знаем их состав и очень примерно — какими они должны быть. Пока не нужно об этом думать — после того, как сдадим Главную страницу, желания заказчика могут смениться на диаметрально противоположные.

Итак, на первом этапе готовим для согласования документ, содержащий:

  1. Детализированные требования к дизайну: корпоративные цвета, количество колонок, общий вид вёрстки блоков, шрифты, стиль иллюстраций.
  2. Детализированные требования к главной странице (обязательно с wireframes), состав блоков, назначение каждого блока, порядок следования и проч.

 
 
Для остальных кусков функционала пишем требования на уровне возможностей: «Каталог позволяет просматривать карточки товаров с возможностью фильтрации, карточки содержат описания товаров и форму обратной связи». Такой детализации пока вполне достаточно.

Есть ли риски в данном случае? Увы, есть. После сдачи первой итерации требования могут измениться настолько принципиально, что результат первой итерации придётся переделать полностью. К сожалению, с этим можно бороться только уменьшением количества требований на итерацию до минимально возможного. Правда, в этом случае возрастают расходы на тестирование (короче итерации — больше регрессионных тестов в единицу времени).

Предположим, первая итерация прошла удачно. Дизайн понравился, главная страница свёрстана грамотно, замечаний немного или нет вовсе. Наши дальнейшие действия — в первую очередь, актуализация плана. Не устарели ли требования? Если всё нормально, переходим к детализации требований на вторую итерацию, иначе корректируем, пересогласовываем, переоцениваем.
 
 
Резюме:

  1. Разбиваем функционал на блоки.
  2. Составляем общий план.
  3. Детализируем требования только к тому блоку, который пойдёт в работу в ближайшую итерацию, остальные блоки описываем на уровне возможностей.

 
 
Такой подход делает разработку предсказуемой и минимизирует риски.

Изображение с behance.net

Карты контрольных проверок

Всё под контролем

Самолёт — слишком сложный аппарат, чтобы подготовить его к полёту по памяти. Некачественная проверка любого узла может привести к катастрофе с гибелью нескольких сотен человек, потере пилотов и самого самолёта. Для исключения подобных ситуаций авиаторы взяли на вооружение карты контрольных проверок.

В США продолжительное время один пациент из пяти тысяч прооперированных умирал из-за ошибки анестезиолога. Внедрение карт контрольных проверок в сочетании со стандартизацией интерфейса оборудования и сглаживанием градиента авторитета (объяснение медсёстрам, что доктор не всемогущ и если они видят ошибку, они обязаны о ней сообщить) привело к снижению смертности до одного пациента на 200-300 тысяч прооперированных (снижение смертности в сорок раз).

Подготовка итерации (в случае ведения разработки по гибким методологиям) зачастую состоит примерно из десятка тривиальных действий. Количество действий зависит от сложности процесса, однако менеджерский опыт автора блога говорит, что ошибки не только возможны, но и весьма вероятны.

Автор работает в организации, в которой менеджер продукта выполняет не столько функции специалиста по развитию, сколько именно организационную работу и обеспечивает качество всего итеративного процесса. Выяснилось, что без карты контрольных проверок слишком легко упустить одно из мероприятий и навредить срокам выпуска версии → разозлить заказчиков, ожидающих выпуск функционала к определённой дате.

Был разработан и внедрён протокол планирования итераций, содержащий перечень мероприятий, даты, отметки о выполнении, а также фамилии сотрудников, ответственных за каждый этап. В качестве инструмента был выбран OneNote. К сожалению, протоколы проведённых итераций содержат конфиденциальную информацию, поэтому приведённый пример будет гипотетическим.

Карта контрольных проверок

Таким образом, процесс состоит из:

  1. планирования работ
  2. написания требований к доработкам
  3. демо требований
  4. старта разработки
  5. кодфриза разработки
  6. регрессионного тестирования
  7. съёмки ролика о новом функционале
  8. передачи билда на поддержку.

Каждый из этапов состоит из группы действий, которые нужно не забыть провести. Некоторые действия (такие, как «Бэклог оформлен в TFS») являются сложными и сами состоят из групп действий, описанных в протоколах нижнего уровня.

Ответственный в данном случае — сотрудник, имеющий полномочия о принятии решения об успешном прохождении этапа. Как видно из примера, за все действия до кодфриза отвечает менеджер продукта Бычко, за выход на кодфриз — тимлид Ригельман, организацию и проведение регрессионного тестирования — глава QA Бунг и, наконец, за съёмки ролика и передачу на поддержку — глава управления продуктом Гольдштейн.

Ниже данной таблицы в протоколе располагается детализированная информация о проведении каждого из этапов. Расшаривание через OneDrive и соответствующие права доступа позволяют ответственным лицам «расписаться» о проведении этапа.

Благодаря внедрению данного протокола практически исключается пропуск любого из шагов, кроме того, все лица, желающие наблюдать за ходом итерации (CIO, глава проектного офиса, глава управления продуктом), могут это сделать, взглянув на протокол через интерфейс веб версии OneNote (или подключив блокнот в десктопной версии приложения).

Изображение с artstation.com