Цитаты из книг автора «Алексей Минкевич»

Требования должны иметь четкий критерий завершенности (definition of done). У менеджера должно быть четкое определение того, что считать выполненным. Кто-то считает, что уборка сделана, когда носки спрятаны под кровать, а для кого-то уборка — это вымытый с содой пол. Хорошие требования — это полные требования. Менеджер обязан собрать их у всех заинтересованных сторон. В самом начале важно не упустить людей, влияющих на проект, и их требования, в противном случае они будут блокировать сдачу проекта. Требования должны быть описаны максимально четко и детально, чтобы их поняли все заинтересованные стороны. Хорошая практика — если вы работаете в IT, дать почитать их кому-нибудь из сферы, не связанной с IT. Если человек поймет, что нужно сделать, значит, работа с требованиями проведена хорошо. Картинка в большинстве случаев говорит лучше слов. Мокап интерфейса — набросок того, как будут располагаться элементы на экране, — всегда лучше фразы «интуитивно понятный интерфейс». Используйте в требованиях как можно больше картинок или прототипов. Самое главное: требования должны быть задокументированы и согласованы со всеми ключевыми заинтересованными сторонами. Документирование — это один из лучших способов избежать разрастания содержания проекта (scope creep). В любом проекте заказчик постарается добавить новые работы, и содержание начнет разрастаться. Лучше всего я прочувствовал это на проектах, где сам выступал заказчиком.

2. Как выглядят хорошие требования? Требования должны быть однозначными, то есть измеряемыми и проверяемыми. Следует избегать размытых формулировок и фраз типа «и т.д., и т. п.», «интуитивно понятный отчет», «дружественный пользователю интерфейс» и тому подобных. Пример из практики. Знакомый бизнесмен, владеющий бизнесом по разработке и внедрению CRM, заключил договор с крупной логистической компанией. В договоре очень хорошо и детально была описана CRM, а также имелась следующая формулировка: «Система должна генерировать следующие отчеты: 1. (описание), 2. (описание), 3. (описание), 4. (описание), 5. (описание), 6. (описание), 7. (описание), 8. (описание), 9. (описание), 10. (описание), и т.д.». После сдачи проекта заказчик не захотел подписывать акт приемки и под пункт «и т.д.» попросил сделать еще один отчет, а потом еще один, и еще… В итоге компания-исполнитель еще год занималась созданием отчетов в рамках контракта абсолютно бесплатно.

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

Есть и другие способы сбора требований. Фокус-группы. Для интервью собирают 5–10 человек из тех, кто будет пользоваться разрабатываемой системой, чтобы выяснить их пожелания. Пользователей у системы может быть огромное количество, но предполагается, что мнения этих 5–10 человек совпадут с мнениями остальных. Семинары с участием модератора. Если заинтересованных сторон не слишком много (до 15 человек), то можно провести специальный семинар по сбору требований. Методы совместной разработки (Joint Application Development, Voice Of Customer, Agile). Команда быстро создает прототип или сильно упрощенную версию продукта (minimum viable product, MVP) и показывает его пользователям. Затем собираются пользовательские отзывы, которые и становятся требованиями. Такими маленькими итерациями список требований обновляется постоянно. Прототипы. Создание чего-то похожего на итоговый результат и демонстрация заказчику. Цель — получить отзыв и понять правильность выбранного направления движения. Обычно прототипирование применяется в тех случаях, когда заказчик сам до конца не понимает, чего именно хочет. Анкеты и опросы. Можно собирать требования при помощи анкет и опросов. Например, создавать их в Google Forms или SurveyMonkey и рассылать пользователям. Наблюдения. Суть в том, чтобы наблюдать, как работает человек или компания. Увиденные действия и процессы документируются для дальнейшей обработки и оптимизации. Бенчмаркинг. Заключается в адаптации лучших решений, применяющихся в других компаниях. Менеджер и команда изучают СМИ, отыскивая лучшие практики и решения у других компаний, а затем применяют их в своем проекте. Анализ существующих документов. Очень часто нужную информацию можно найти в существующей документации или переписке.

1. Как собирать требования к проекту? В 90% случаев требования к проекту собираются с помощью интервью. Менеджер встречается с заказчиком и заинтересованными сторонами и выясняет, что именно им нужно и как это должно работать. Затем перекладывает все на бумагу и согласовывает получившийся список.

Существует три базовых плана: по содержанию работ, по стоимости и по расписанию (вспомните треугольник управления проектами). Все эти планы связаны между собой. Изменения в одном из них повлекут изменения и в других. Например, если к нашему проекту встречи с друзьями добавляется работа «испечь торт к чаю», то это, соответственно, увеличит бюджет проекта и изменит его расписание. Любые коррективы в базовых планах необходимо согласовывать со спонсором. Это значит, что менеджер проекта не может единолично вносить изменения в них (менять содержание работ, бюджет или расписание). В то же время важно понимать, что менеджер проекта может влиять на базовый план. Как именно? Предложить заказчику новое видение проекта или конкретные изменения. Если изменения устроят все стороны, то можно запускать процедуру внесения изменений в базовый план. Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.

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

В первоначальной версии проекта такой функционал не был предусмотрен. В такой ситуации менеджеру лучше сразу же прописать в исключениях, что сайт в рамках конкретно этого проекта разрабатываться не будет. Возможно, эта работа войдет в содержание одного из следующих проектов, но не этого. Почему? Порой возникают случаи, когда все забывают о таком разговоре. Все, кроме директора по маркетингу. И вот уже несколько месяцев идет проект, но тут директор по маркетингу решает узнать, как продвигается разработка сайта. Он обращается к непосредственному руководителю менеджера: мол, помните, мы обсуждали такую-то идею? Как там дела обстоят? Руководитель вспоминает, что действительно был такой разговор, и идет к менеджеру. И вот здесь менеджеру хорошо бы иметь документ, в котором будет написано, что сайт — это другой проект. В противном случае конфликта не избежать. Некоторые заказчики чувствительны к формулировке «исключения из проекта»: «Мне это нужно! В смысле — не будем делать?!» В таких случаях этот пункт можно назвать «работа, которая будет выполнена в следующем проекте / на следующем этапе проекта». Ограничения проекта (Project constraints) — это то, в чем нас ограничивает заказчик: например, в выборе субподрядчиков или технологии. Не нужно вписывать в этот пункт ограничение по срокам и бюджету: им всегда отводится особое место. Допущения проекта (Project assumptions) — факторы в рамках процесса планирования, которые считаются верными без предоставления доказательств и демонстраций. Здесь же описывается влияние этих факторов на проект. Это предположения, с которыми согласны и вы, и спонсор проекта. Без этих предположений дальнейшее планирование проекта невозможно. В случае, если допущение не срабатывает, проект обычно требует изменения подхода и серьезного перепланирования. Например, если мы предполагали, что существующая инфраструктура в состоянии поддержать работу нового программного обеспечения, но это оказалось не так — придется или покупать новый сервер, или вносить в систему существенные изменения, которые позволят ей работать на старом железе. Возможно, вообще понадобится написать новую систему, используя другую технологию.

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

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