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

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

Внедрять систему управления изменениями лучше в самом начале проекта. А еще лучше — обсудить ее с заказчиком до того, как приступить к работам. Необязательно использовать какой-либо сложный инструмент для документирования изменений, можно обойтись простым документом. Главное, чтобы всем сторонам это было удобно. Если менеджер планирует внедрить управление изменениями на давно идущем проекте, где все прихоти заказчика исполняются и он к этому привык (и ничего менять не хочет), единственным аргументом в дискуссии с ним будет то, что компания-подрядчик перешла на новый процесс работы с изменениями и менеджеру необходимо ему следовать. Помните, что любые изменения в проекте могут привнести в него новые риски, поэтому не нужно забывать анализировать влияние изменений на проект и с этой точки зрения. Скептики скажут: «И что? Теперь на каждый чих заводить форму запроса на изменение и утверждать? Часто дел там всего на пару минут». Замечание справедливое. В случае незначительных изменений следует заранее согласовать со спонсором проекта определенное количество оплаченных часов на такого рода работы, а также согласовать само определение «незначительных работ». Например, считать таковыми те, которые отнимают не более двух часов. Если сразу очевидно, что изменение небольшое, то оно делается по упрощенной схеме. При этом нужно отслеживать все запросы на мелкие изменения. В случае, если мы исчерпали согласованные часы, необходимо обговорить со спонсором новый объем времени на подобные работы. Менеджер должен организовать работу таким образом, чтобы все изменения в проект вносились с его ведома: управлять тем, о чем не знаешь, очень сложно. Почему это важно? Общаясь с заказчиком напрямую, ваш разработчик, например, может пообещать ему что-то сделать. Возможно, он действительно может выполнить обещание, но, в отличие от менеджера, разработчик не видит всего проекта целиком. Следовательно, он не знает, как его обещание скажется на работе других команд, в каком месте их интересы пересекаются и не вызовет ли это новых ошибок. Задача менеджера — выстроить такую систему, при которой со всеми изменениями заказчик шел бы прямо к нему, а не к кому-то из команды.

4. Идентификация влияния изменений на содержание проекта, сроки, стоимость и качество. Вместе с командой проекта необходимо оценить, как именно запрашиваемое изменение повлияет на содержание существующих работ проекта, расписание, бюджет и качество. 5. Оценка затрат, преимуществ и выбор альтернативы. Обычно существует несколько способов выполнить запрос на изменение. Заинтересованная сторона проекта, запросившая изменение, не всегда может предложить оптимальный вариант, и команда проекта должна подумать, как достичь такого же результата иначе и с меньшими усилиями. Из ярких примеров: проект по доработкам внутренней системы анкетирования сотрудников. Заказчик попросил добавить возможность отправки определенного шаблона опросника выбранным сотрудникам. Подобный функционал требовал трех недель разработки. При детализации запроса выяснилось, что необходимо учитывать профессиональную позицию сотрудника, указав ее в начале анкеты: разработчик, тестировщик или бизнес-аналитик. Команда предложила добавить в опросник возможность кастомизации и импорта полей из карточки сотрудника. Подобная альтернатива предоставляла заказчику гораздо более гибкое решение, и на ее реализацию нужно было потратить всего одну неделю. Заказчик с радостью утвердил данное решение и был им очень доволен. 6. Оценка стоимости изменения. Необходимо посчитать, сколько будут стоить работы или как долго они будут выполняться при разных вариантах исполнения запроса на изменение. 7. Принятие решения о включении изменения в проект. Спонсор проекта выбирает одну из предложенных альтернатив, утверждает ее и все расходы на реализацию. Затем команда забирает изменение в работу. 8. Обновление документов проекта и внедрение изменения. Обычно изменение добавляет в проект определенные работы. Поэтому после утверждения изменения новые задачи нужно добавить в иерархическую структуру работ проекта, его бюджет и расписание. После этого можно приступать непосредственно к реализации запроса. 9. Документирование решения и информирование заинтересованных сторон. Перед внесением любых изменений нужно создать или обновить документацию, где детально будет описано, как именно работает дорабатываемая система сейчас. Это особенно важно в проектах, которые длятся много лет, иногда десятилетиями. Такая документация позволит отследить историю изменений проекта и найти причину проблем, если они вдруг возникнут.

Как работать с изменениями в проекте Схематично процесс работы с изменениями выглядит следующим образом (рис. 57). Давайте рассмотрим его детальнее. 1. Идентификация изменения. В этом помогает форма запроса на изменение. Как правило, это простая форма, доступная через интернет (в Google Forms или любом другом аналогичном сервисе). Имя инициатора и время заполнения определяются автоматически, поэтому заполнить нужно всего одно поле — описание запроса (рис. 58). В чем полезность этой формы? Часто заинтересованная сторона проекта сообщает, что возникла необходимость или желание что-то в проекте изменить. Человеку пришла в голову замечательная идея, и он спешит ею поделиться. В этом случае руководитель проекта должен попросить заполнить форму запроса на изменение. Человеку нужно будет описать свою идею — и тем самым фактически расписаться в ее авторстве. И вот на этом этапе исчезает достаточно много замыслов: после изложения идеи в письменном виде она часто уже не выглядит такой привлекательной. Удобство формы также в том, что менеджер не забудет об изменениях, как часто бывает, если запрос поступил в телефонном разговоре. 2. Уточнение содержания. Когда запрос на изменение получен, нужно убедиться, что менеджер его верно понял. При необходимости следует уточнить содержание запроса у инициатора. Полученная информация также должна быть отражена в форме. 3. Оценка сложности и стоимости рассмотрения изменения и принятие решения об анализе изменения. Иногда встречаются настолько сложные запросы, что только для их оценки требуются недели. В таких случаях нужно подготовить оценку трудоемкости рассмотрения изменения и согласовать ее со спонсором проекта. Далее уже он решает, нужно ли проводить оценку. В нашей практике нередко случалась примерно такая переписка: «Привет! Нужно добавить вот такой функционал» (далее идет описание). — «Привет! Это сложное изменение. Архитектору нужно будет потратить неделю рабочего времени, чтобы понять, сколько оно будет стоить и как повлияет на сроки». — «Хм. Я не думал, что это такая сложная штука. Тогда не нужно». В этом случае спонсор проекта не согласовал оценку изменения, и мы сразу отправили запрос в архив. Почему не удалили? Архив нужен, чтобы указать спонсору на принятое ранее решение в том случае, если он снова придет с этой же идеей. Если же спонсор утверждает затраты, необходимые на анализ изменения, или анализ можно провести очень быстро, то мы переходим к следующем пункту.

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

Изменение — это любое отклонение от ранее одобренного базового плана. Оно может повлиять на основные ограничения проекта: расписание, содержание и стоимость, а также на качество и на удовлетворенность заказчика. В лучшем случае изменения затронут какой-то один план, но чаще всего — все. Например, есть проект длительностью два месяца и стоимостью 10 000 руб. Заказчик вносит корректировки и добавляет к проекту дополнительную работу длительностью две недели и стоимостью 3000 руб. После согласования новых сроков и стоимости меняются базовые планы проекта, в содержание добавляется работа. Из-за этой корректировки обновится и расписание: проект будет длиться два с половиной месяца. Изменится базовый план по стоимости: она вырастет до 13 000 руб. В этом примере поменялись все три базовых плана. Именно поэтому управление изменениями называется комплексным: корректировка одного из базовых планов обычно влечет изменение остальных. Современное программное обеспечение по управлению проектами, например Microsoft Project, связывает эти планы воедино, так что как только меняется один, автоматически обновляются и остальные. Это удобно.

В каждом приключении надо сделать первый шаг… Да, банально… Но даже здесь это работает. Льюис Кэрролл

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

Многие руководители жалуются на своих подчиненных. Дескать, как можно говорить о качестве, когда человек не может самостоятельно выполнить простейшее поручение, что ни сделает — все не так. Вроде и процессы есть, и инструкций вагон, а он все равно не может качественно выполнять свои обязанности. Такой ситуации можно было бы избежать, если бы руководитель изначально проверил членов своей команды по некоторым пунктам. Понимает ли человек, чего от него ждут и какой результат предполагается получить после выполнения порученного задания? Имеет ли человек необходимые теоретические знания для выполнения порученной работы? Знает ли исполнитель о существовании определенного процесса или инструкции, согласно которой должно быть выполнено задание? Если да, то ознакомлен ли он с ней? Выполнял ли человек подобное задание ранее? Теоретические знания — это, конечно, хорошо, но без практических навыков они не позволяют гарантировать результат. Владеет ли человек инструментарием для выполнения работы? Незнание всех возможностей инструментария серьезно замедляет процесс и блокирует достижение результата нужного качества. Понимает ли человек, как оценить результат во время выполнения работы? Неумение распознать ошибку на раннем этапе может сделать установленные критерии качества недостижимыми, а отсутствие эталона (примера, к которому нужно стремиться) — вызвать у человека иллюзию того, что лучше уже не будет. Хочет ли человек выполнять данное задание? Последний в списке, но не по значимости пункт. Отсутствие желания зачастую делает невозможным достижение результата необходимого качества. Чтобы работа выполнялась стабильно и качественно, важно, чтобы команда придерживалась всех договоренностей. И здесь есть особенности: если у вас в команде собрались сплошные «звезды», то вы сможете выполнить один проект блестяще, но это совершенно не гарантирует стабильного результата в долгосрочной перспективе. Нужно учитывать, что «звезды» не всегда придерживаются правил. А порядок чаще всего бьет класс.

Работа с качеством неразрывно связана с постоянным совершенствованием. Постоянное совершенствование (Continuous improvement) — это освоение новых операций и отказ от тех, которые оказались малоэффективными или не имеющими ценности. Цель постоянного улучшения — повышение эффективности выполняемой работы за счет сокращения затрат, количества ошибок и потерь (доработка, время, трудоемкость, материалы и др.). Говоря о совершенствовании, мы подразумеваем цикл Деминга — Шухарта, который состоит из следующих шагов: планирование (Plan) — изучение имеющихся проблем, определение первопричин, планирование необходимых изменений и определение метрик, на основании которых можно будет сделать вывод об удачности/неудачности внесенных изменений; реализация (Do) — внедрение запланированных изменений (желательно в малом масштабе), чтобы собрать эмпирические данные для дальнейшего анализа; проверка (Check) — анализ полученных данных на основании определенных ранее метрик и оценка успешности внесенных изменений: что пошло по плану, что получилось не так, как было запланировано, а что вышло даже лучше, чем представлялось ранее; действие (Act) — внесение изменения и новые попытки.