Правила эффективного старта проектов

Меня зовут Настя, я Unit Manager международной команды в компании Itransition и тренер по управлению проектами в IT-Academy. За более чем 5 лет опыта в менеджменте мне довелось поработать с разными заказчиками, продуктами, командами. На старте карьеры меня удивляло, что, согласно статистике PMI, из года в год более половины проектов заканчиваются крахом.

Сейчас я охотно верю этим данным, ведь сколько IT-проектов я ни стартовала, не было ни одного, чтобы все шло идеально. Я также не знаю ни одного практикующего менеджера, у которого бы всегда все шло как по маслу (те, с кем я познакомилась на собеседованиях, не считаются ☺). Как ни печально, многих трудностей можно было бы достаточно легко избежать, или, как минимум, облегчить ход развития событий, предприняв определенные шаги на самом старте проекта.

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

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

О чем многие знают, но часто забывают

Договор

Что является отправной точкой для старта проекта? В IT-аутсорсе, как правило, — подписание контракта. Но почему-то этот самый контракт менеджеры не считают нужным прочитать. Постараюсь кратко описать, что полезного там можно найти помимо всем известных сроков и стоимости поставки:

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

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

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

Например, в допущениях указано, что заказчик предоставит готовые API для разработки front-end. Соответственно, есть риск того, что это допущение окажется ошибочным. В таком случае команде придется как минимум приложить дополнительные усилия на интеграцию с серверной частью приложения. Задача менеджера — определить, насколько сильным будет влияние на проект риска, что допущение окажется ошибочным, и составить план «Б».

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

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

Я указала только три пункта, но договор нужно и важно читать полностью, вдумчиво! На моей практике были примеры, когда менеджер обещал клиенту гарантию, руководствуясь своим опытом работы с контрактами в другой компании, хотя в текущем контракте она не была прописана. Бывало, что осуществляли замену членов команды, не соблюдая условия договора, что влекло за собой праведный гнев заказчика. А ведь можно было этого легко избежать.

Устав проекта

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

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

Kick-off Meeting или встреча по инициации проекта

Я бы сравнила kick-off с первым свиданием: от того, как пройдет первое, во многом зависит, будет ли второе. Да, отношения с заказчиком подкреплены договором, но никто не застрахован от эскалации и просьбы сменить менеджера. Только вот почему-то далеко не всегда к kick-off готовятся так же трепетно, как к первому свиданию. Я не буду говорить про повестку встречи, но вот на что я рекомендую обратить внимание:

— Подготовьтесь и проведите внутренний kick-off. Это позволит вам отрепетировать звонок с заказчиком, пообщаться с командой, с pre-sales, собрать всю возможную информацию и создать список открытых вопросов. Как результат, вы будете более подготовленными и менее тревожными.

— Подготовьте презентацию. Она сильно облегчит вам задачу как докладчику и позволит всем участникам встречи легче улавливать информацию, быть всегда в одном контексте. Инструментов для этого достаточно: Microsoft Power Point, Miro, Prezi — выбор на любой вкус.

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

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

— Вышлите follow-up и приглашения на последующие встречи. Если вы не задокументируете ваши договоренности, будьте уверены, о них забудут или, что хуже, в момент наступления проблем будут использовать не в вашу пользу.

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

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

О чем мало говорят, но было бы полезно использовать

Team Charter или манифест команды

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

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

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

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

Onboarding Guide или руководство для новичков

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

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

Communication plan или план коммуникации

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

Обычно создаю на Confluence страницу под названием Communication plan, где располагается таблица. Верхняя строка таблицы представляет собой таймлайн, то есть схему рабочей недели или месяца (зависит от продолжительности итераций, по которым выстраиваются рабочие процессы). Следующие строки посвящены инструментам коммуникации, обычно это встречи и разного рода отчеты.

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

Реестр юридических документов

Здесь все просто: чтобы ничего важного не потерять и не забыть, лучше сразу все хранить в одном месте, будь то папка на Sharepoint или страничка на Confluence. Важно помечать «срок годности», чтобы вовремя обновлять необходимые документы.

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

Заключение

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

👍НравитсяПонравилось8
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

хотел написать что залог эффективного старта это собрать всех участников и нормально забухать, но потом почитал что тут пишут и понял что это пишет суровый украинский проджект менеджер. И теперь мне кажется что я не могу пройти мимо и не исправить эти ошибки преподавателя. 1. 80 процентов проектов не вписываются в тайм-прайс-кволити ограничения, это не делает их неуспешными с экономической точки зрения и они не заканчивается крахом как тут сказанно. Они заканчиваются позже, дороже и с большим списком переделок, но не крахом. 2. Assumptions, называется регистр допущений, туда вносятся предположения которые не удалось подтвердить на момент принятия решенья. В начале проект это могут быть только какие то высокоуровневые допущения, никого не парит что там на бек энде будет. В жизни регистр допущений встречается редко потому что все обычно можна проверить до принятия решений, а вот регистр рисков встречается всегда но он почемуто тут пропущен. 3 Манифест команды — это ж вроде документ который описывает зону ответсвенности или роль команды в проекте. Что бы фронт энд не мешал дев опасам. Там нету описания у кого какая роль внутри этой команды. В жизни манифест команд не встречается, все как правило и так знают за что отвечает. 4. Онбординг членов команды — это не уровень проджекта менеджера, этим занимается функциональный менеджер. 5. Communication plan — в нем описываются ключевые люди кому нада отправлять новости и отчеты, что бы стейкходеры были вкурсе дела что происходит или если нада кого то запушить то кто может в этом помочь. Сюда же можна добавить таймлайны когда/кого/ о чем нада информировать, но вначале список людей и контактов, а потом расписание. Ну как то так ))) суровый украинский проджект исказил 50% информации

Дякую, дуже корисно! Чекаю на продовження!

Есть две основных причины неудачи IT проектов:
1. PM, который не может сказать ни «нет», ни даже «да, но...» стейкхолдерам.
2. PM, который говорит «да, но...», выбивает дополнительный бюджет, но использует его для иных целей.
Остальным можно пренебречь.

Есть доля проектов, заканчивающихся крахом. Но в производстве, а IT это именно производство, показатель 50% явно говорит о дерьме

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

Спасибо!

Это была очень интересная и познавательная для прочтения статья. Уверен, многим эта информация будет полезна для практического использования.

Якщо б ще була написана державною мовою або хоча б англійською — то ціни б їй не було.
А так — взагалі не зручно читати.

Подписаться на комментарии