В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки. Это должно быть интересно как новичкам в таком непростом деле, как менеджмент проектов, так и начинающим стартаперам, и возможно, опытным менеджерам.
Что же такое проект?
Проект – одноразовая, неповторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.
В определенном смысле все проекты одинаковы. У всех есть потребитель (и) и или покровитель (и), которые ждут от реализации проекта достижения в определенное время результатов. Проекты часто реализуются с целью создания чего-то нового или осуществления больших изменений, которые можно рассматривать как завершенный вид деятельности. Проект может возникнуть исходя из новых запросов потребителей или пользователей услуг, либо из возможности получить выгоды для организации, либо на основании новых потребностей организации.
- они являются целевыми, т.е. вся деятельность направлена на достижение определенных результатов или выходов;
- они имеют четкое начало и конец;
- у них есть определенные ограничения, которые лимитируют и определяют процесс;
- достигнутые результаты могут быть измерены с помощью согласованных показателей.
- проект не уложился в рамки бюджета;
- проект занял большее время, чем было запланировано;
- проект завершен в рамках бюджета и намеченного времени, но не удовлетворяет по качеству.
Не существует единственно «правильного» способа управления проектом. Традиционные подходы к управлению проектами сфокусированы на технических аспектах, и влиянию людей на реализацию проекта нередко уделяется меньше внимания. Однако именно люди заказывают и поддерживают проекты, поэтому лидерство, мотивация и управление вовлеченными в проект людьми так же важны, как и использование подходящих методов планирования, контроля и мониторинга.
Рассчет финансовой модели, бизнес-план
Часто встречающиеся недостатки в реализации проектов:
- в команде были сомнения по поводу целей проекта;
- команда не была уверена в том, что должно быть сделано;
- к концу проекта цели были достигнуты только частично;
- работы выполнялись позже намеченных в графике сроков;
- запланированный бюджет был превышен;
На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):
- ясно поставленные цели;
- четкое планирование и контроль;
- высокая квалификация менеджера проекта;
- хорошая административная поддержка;
- достаточное количество времени и ресурсов;
- выполнение своих обязательств всеми участниками;
- широкое привлечение потребителей;
- хорошие коммуникации;
- хорошая организация и структура проекта;
- возможность прекратить реализацию проекта.
Определение границ проекта
Проект начинается с идеи и возникает с целью удовлетворения потребностей человека. Идея состоит в том, чтобы сделать что-то, что кажется необходимым. Преобразование идеи в проект начинается с понимания природы потребности как движущей силы. Поэтому потребности являются основной движущей силой проекта.
Кассовый разрыв в бизнесе, бизнес-плане, инвестиционном проекте. Что это такое? Как избежать? | ч.1
- Появление потребностей — все заинтересованные стороны должны предупреждать и предвидеть потребности, реагируя на них проактивно;
- Признание потребностей — осознание потребностей на основе сбора информации и обсуждения с ЗС. Главная задача на этом этапе – превращение возникающей потребности в цели, которые начнут определять результаты проекта;
- Формулирование потребностей — прояснение понимания потребности с помощью более точного описания ее характерных особенностей. Формулировка того, что должно быть сделано, т.е. определение границ, формулировка проекта.
Проблемы недостаточно точного определения потребностей:
- нечеткие цели;
- нереалистично широкий масштаб;
- решение неверно поставленных проблем;
- противоречивые цели изменений для людей, систем, организации;
- потеря времени на выполнение задач, которые не входят в круг обязанностей людей, необязательны или невыполнимы.
Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:
- Кто является заинтересованными сторонами (ЗС) и каковы их потребности в проекте?
- Каковы цели и задачи проекта и каким образом их собираются осуществить в рамках соответствующих ресурсных и временных ограничений? (предназначение и цели)
- Каковы возможности проекта и угрозы для его успешной реализации?
ЗС и их потребности
- Покровитель проекта – человек или группа людей, которые инициируют и поддерживают проект, обеспечивают ресурсами и поручают Вам его реализацию;
- Команда проекта – группа людей, готовых выполнять поставленные задачи и осуществлять необходимые виды деятельности; 3.Функциональные менеджеры и другие люди, которые управляют необходимыми Вам ресурсами и обладают полезными для Вас опытом и знаниями;
- Влиятельные люди или группы, которые, вероятно, подвергаются воздействию проекта или его результатов
В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:
- потребители, покупатели, пользователи товаров и услуг;
- другие работники организации (из этого или другого подразделения);
- менеджеры и персонал организаций-партнеров;
- высшее руководство Вашей организации;
- акционеры и их представители;
- СМИ;
- конкуренты;
- общественные и государственные деятели, если проект вызывает широкий общественный интерес.
После того, как установлены основные ЗС, эту информацию необходимо использовать для того, чтобы обеспечить проекту максимально возможную поддержку. Обязательно нужно проверить, как реагируют на проект люди до того, как в процессе планирования будут исключены другие варианты его реализации. Если эту возможность использовать в полной мере, то команда проекта узнает о многих потенциальных препятствиях и будет хорошо информирована о приоритетах каждой группы. Один из способов понять реакции разных ЗС является анализ их точек зрения на каждое из ключевых измерений проекта – бюджет, время и качество.
Определение предназначения и целей проекта
Предназначение проекта является широким понятием и может быть соотнесено с миссией и ценностями организации, тогда как цели проекта определяют более точно, чего стремятся достичь, реализуя проект, и каким образом можно определить его успех.
Цели должны соответствовать критериям SMART:
- конкретными (specific) – т.е. Вы должны ясно представлять себе, чего хотите достичь;
- измеримыми (measurable) – Вы должны разработать критерии для измерения процесса достижения целей;
- достижимыми (achievable) – т.е. Вы должны быть уверены в достижении поставленных целей в существующем окружении и при имеющихся ресурсах;
- реалистичными (realistic) – т.е. Вам не следует пытаться достичь невозможного;
- определенными по времени (timebound) – т.е. сроки достижения поставленных целей должны диктоваться реальными потребностями
Поставленные цели дают возможность определить шаги, с помощью которых может быть реализовано предназначение проекта и не позволить сбиться с правильного пути; использоваться для того, чтобы убедиться, что проект хорошо вписывается в деятельность организации.
Ясность целей важна для понимания того, что должно быть сделано. Если поставлены четкие цели, то это значит, что имеется определенная система взглядов на конечный результат. На основании поставленных целей происходит структурирование проекта с тем, чтобы его можно было эффективно контролировать и управлять им. Однако иногда возникает необходимость в пересмотре целей, поскольку в процессе осуществления проекта могут возникнуть новые обстоятельства, неизвестные на стадии планирования. Поэтому цели не должны быть «каменными».
Возможности и угрозы
Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.
Проверка осуществимости проекта
- финансовые — проведение сравнительного анализа ресурсных затрат проекта вместе с предполагаемой прибылью и затрат, которые могут появиться, если проект не будет реализован;
- технические — определение того, каким образом новая система будет связана с существующими системами, будут ли организация и работники подготовлены к работе с новой технологией и как управлять процессом перехода;
- влияние внешнего окружения и общества — беспокойство ЗС по поводу влияния внешнего окружения, воздействия проекта на внутреннее окружение и местные социальные условия;
- управленческие — исследование ресурсов для новой практической деятельности, включая потребность в новых работниках или обучении имеющегося персонала, изменения сроков и условий работы, а также принцип равных возможностей;
- ценностные — изучение мотивационных вопросов и вопросов культуры с целью убедиться в том, что проект
- какова бизнес-причина для выполнения проекта?
- какой вклад внесет проект в достижение общих целей организации?
Затраты и выгоды для оценки проекта
- стоимость разработки- затраты, возникающие в период между началом проекта и моментом, когда начато производство продукции. Они присущи всем проектам и обычно включают в себя затраты на команду проекта.
- операционные затраты – затраты, возникающие с началом выпуска продукции и обеспечивающие поддержание данного процесса (пример – ежедневно расходуемые материалы, используемый капитал). Они не возникают в проекте, в котором продукт продается один раз сразу после завершения проекта.
- осязаемые выгоды — прямые, видимые и измеряемые выгоды, обычно базирующиеся на денежных потоках, которые поступают в организацию или больше не уходят из организации;
- неосязаемые выгоды — косвенные, неопределенные и менее легко измеримые с финансовой точки зрения выгоды (более высокое качество услуги, возросший ассортимент).
- затраты и поступления, которые влекут за собой денежный обмен;
- альтернативные поступления и затраты, такие как продажа активов, которые могли бы принести определенный доход;
- потерю дохода или рост затрат в связи с отвлечением штата или потребителей услуги, которые появились в связи с проектом;
- экономия, возникающая в результате замены менее эффективных систем новыми, которые предусмотрены проектом.
- Чистая текущая стоимость (Net Present Value — NPV);
- Внутренняя норма отдачи (internal rate of return — IRR);
- Срок окупаемости;
- Анализ эффективности затрат.
Риски и ситуационное планирование
- Выявление риска – определение, какие риски могут влиять на проект, и описание характеристик каждого из них.
- Оценка влияния – оценка риска с точки зрения диапазона возможных результатов, касающихся проектов, и потенциального влияния каждого из них.
- Планирование запасных вариантов с целью снижения влияния наиболее вероятных рисков.
- Обеспечение того, что риски всегда находятся в поле зрения.
- материальные риски – возможность утраты или повреждения информации, оборудования или зданий вследствие несчастного случая, пожара или стихийного бедствия;
- технические риски, возникающие когда системы не работают или работают недостаточно хорошо для получения необходимых результатов;
- кадровые риски – вероятность неучастия ключевых работников в реализации проекта или недостаток квалифицированных кадров;
- социально-политические риски, возникающие, когда проект лишается поддержки вследствие смены власти, изменений в политике высшего руководства организации или протестов со стороны общественности, СМИ, пользователей услуги или персонала;
- правовые риски – угроза правовых действий из-за того, что некоторые аспекты проекта могут рассматриваться как незаконные.
Существует несколько способов выявления риска. Это в первую очередь обсуждение проекта с ЗС и рассмотрение различных перспектив, в ходе которых отдельные ЗС могут увидеть угрозы их интересам. Очень важно оценивать риск на каждом этапе реализации проекта и планировать возможные способы уменьшения его влияний. Там, где риск можно предвидеть, необходимо разработать ситуационный план, который можно применить, если ситуация риска реализуется.
Оценка риска и анализ влияния: ключевые вопросы
- что такое риск – как я его узнаю, если он возникнет?
- какова вероятность его осуществления – высокая, средняя или низкая? насколько серьезную угрозу он представляет для проекта – высокую, среднюю или низкую?
- каковы признаки или причины риска, которые нам следует искать?
- Избежание риска — например, отказ от контракта;
- Снижение риска — например, регулярные проверки могут снизить вероятность производства продукта низкого качества;
- Защита от риска — например, страхование от возможных случайностей;
- Управление риском — например, использование письменных соглашений в тех сферах деятельности, где возможны разногласия;
- Перемещение риска — например, передача ответственности за выполнение рискованного задания в рамках проекта другой организации, у которой больше опыта.
Основание для действий по проекту
- ожидаемым результатам;
- ресурсам, которые будут вложены для достижения этих результатов;
- времени, необходимому для достижения этих результатов.
- Название проекта;
- Покровитель проекта;
- Местоположение – адрес покровителя, местоположение проекта, контактные адреса;
- Имя менеджера проекта и название его организации, если она отлична от организации, спонсирующей проект;
- Дата согласования резюме с покровителем проекта;
- Дата начала и завершения проекта;
- Обоснование и предназначение проекта с обзором основных идей;
- Основные цели с указанием критериев качества и успеха;
- Подробное описание того, как достижение этих целей принесет выгоды бизнесу или организации, спонсирующей проект;
- Масштаб и границы проекта;
- Ограничения;
- Предположения;
- График проекта;
- Основные результаты и соответствующие им даты (вехи проекта);
- Оценка затрат;
- Механизмы обеспечения ресурсами;
- Механизмы отчетности и мониторинга;
- Механизмы принятия решений – полномочия и подотчетность менеджера проекта и проведение повторных переговоров;
- Механизмы и каналы коммуникаций;
- Подпись покровителя проекта с указанием даты, звания и должности
Заключение
В данной статье, как можно более кратко и конкретно, были рассмотрены теоретические основы этапа подготовки проекта. Для этого использовалась литература Школы бизнеса МИM ЛИНК, выпускником которой и является автор. В учебном курсе данной школы подробно изучается шестиэтапная модель управления проектом, и если появится заинтересованность со стороны хабрасообщества, можно будет продолжить серию статей на эту тему.
Источник: habr.com
Регламент по управлению качеством в проекте 108 Организация управления качеством 113
Бизнес-цель – это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится «просто выдать продукт», а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта).
Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений для обеспечения ее развития и роста.
Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО, или бизнес-кейс, проекта.
Разработка устава проекта
Устав проекта – это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.
Процесс разработки устава проекта уже подразумевает, что компания заинтересована в достижении какой-то цели или решении имеющейся проблемы и готова выделять под это ресурсы. Следовательно, со стороны организации-заказчика есть мотив инвестировать средства и ресурсы в генерацию такой информации, которая позволит разработать корректный устав проекта. К информации, имеющей ключевое значение для составления устава, относятся:
- стратегические и тактические цели организации-заказчика;
- формулировка требований организации-заказчика;
- ТЭО;
- контракт;
- внутрикорпоративная методология управления проектами и соответствующие политики.
В Таблица 5 приведены требования к уставу проекта – перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.
Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы.
Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий – это только создаст дополнительные ограничения для выбора методологии реализации проекта.
Далее (см. Рисунок 2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники – участники, овалы – факторы окружения) [20]
- компетенции команды проекта достаточно для выполнения предпроектного обследования;
- организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта.
Пример ограничений проекта:
- увеличение стоимости проекта не более чем на 10%;
- не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.
Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта – объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта
Роль спонсора проекта обычно берет на себя (не назначается. ) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2 . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
- утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения;
- назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения;
- формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;
- вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов;
- принимать решения о внесении изменений в базовую линию проекта.
Администратор (координатор) проекта – это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить:
администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. сбор статуса – словосочетание, не несущее смысла, если только это не специфический термин. Я прошу обратить на него внимание. М/б, сбора информации о текущем статусе?
Формировать всю команду и тем более сразу указывать имена всех ее членов не принято – функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденные спонсором проекта [18]
Источник: dogmon.org
Бизнес причина возникновения проекта это
Оценка проектов, планирование и неопределённость
Кто прав, бизнес или специалисты?
Цель любого проекта — создание инструментов, используемых бизнесом. Это может быть онлайн-магазин, через который компания продаёт товары, или банковский сервис для взаимодействия с клиентами, или мобильные приложения, используемые на складе сотрудниками логистической компании.
В большинстве случаев для поддержания всех процессов требуется одновременно несколько инструментов. Часть из них создаётся на заказ непосредственно для бизнеса, часть подбирается из готовых продуктов либо внешних сервисов. Если бизнес развивается, то вместе с ним развиваются и цифровые инструменты. Т.к. внешняя среда любой компании все время меняется, то и сама компания должна непрерывно адаптироваться. А значит, любой действующий бизнес находится в постоянном процессе обновления своей инфраструктуры, в том числе и цифровой.
Чаще всего это обновление заключается в совершенствовании уже существующих инструментов. Компания может менять ассортимент продаваемых
товаров или расширять свои услуги, но основная схема работы остаётся без изменений. В таких случаях достаточно небольших доработок. То же самое можно сказать про обновление дизайна или изменения в интерфейсе. К примеру, если речь идёт про онлайн-сервис, то более простое взаимодействие с клиентами может увеличить продажи, при этом бизнес-модель компании сохраняется.
Но бывают случаи, когда требуется что-то более радикальное, нечто, что меняет правила игры, давая бизнесу возможность построить свою работу способом, отличным от конкурентов, или создав принципиально новую бизнес-модель. Это типичный сценарий для успешных стартапов, хотя традиционные компании тоже периодически делают подобные попытки, которые, как ни странно, иногда заканчиваются успехом.
Конечно же, бизнес не решает такие задачи самостоятельно, а привлекает специалистов из ИТ-индустрии. В предыдущей главе я как раз описал внутреннюю кухню этой отрасли, дал описание типов проектов, форматов работы, объяснил, как устроена экономическая модель проектных команд и компаний,
создающих цифровые продукты и сервисы. Независимо от того, работают ли ИТ-специалисты внутри или бизнес заказывает проект у сторонних технологических компаний, взаимодействие бизнеса и профессионалов — не самая простая задача. Многие проекты завершаются, либо значительно превышая ожидаемые сроки и стоимость, либо без требуемого результата. Но чаще всего происходит и то, и другое. Только в отдельных случаях бизнес получает то, на что изначально рассчитывал.
Вы, наверно, уже догадались, что эта глава посвящена проектной работе, т.е. процессу превращения бизнес-задач в действующие цифровые инструменты. Но в то же время эта глава о неочевидных причинах того, почему не удаётся реализовать такие проекты. Почему неочевидных? Потому что с точки зрения бизнеса причины кажутся простыми и понятными: к проекту привлекли специалистов, которые не смогли уложиться в сроки или реализовали продукт плохого качества. С точки зрения профессионалов, создающих цифровые продукты, причина тоже не вызывает сомнений: бизнес не смог чётко поставить задачи, а на реализацию выделил
слишком мало времени и сократил бюджет. Ключевым моментом для понимания является то, что речь может идти об одном и том же проекте. Точка, с которой вы смотрите на реальность, влияет на ваше представление о ней и открывает иную перспективу. Или её отсутствие.
Для пешехода, который погибает, переходя дорогу на зелёный свет, но не глядя по сторонам, единственной радостью остаётся то, что он был прав. Так и бизнес часто настаивает на своей формальной правоте, говоря, что раз уж продукт был заказан, то он непременно должен быть получен в требуемом виде. Не понимая природы проектной работы над цифровыми продуктами, бизнес часто теряет время и деньги, а иногда рискует собственным существованием. Цена вопроса, как мне кажется, слишком высока, чтобы продолжать настаивать на своём и не пытаться разобраться в действительных причинах проблем.
То же самое можно сказать и про профессионалов. Немногим людям, имеющим отношение к цифровым продуктам, посчастливилось поработать с обеих сторон
проектных баррикад. Знание того, что происходит на противоположной стороне, даёт более глубокое понимание возникающих проблем. Как следствие, проекты, выполняемые такими людьми, с большей вероятностью достигают успеха. Ильяху Голдратт называл попытку поиска компромисса между разными точками зрения способом создания иллюзии.
Эти же люди лишены подобных иллюзий, и в таком ясном взгляде и заключена их ценность. Многие проекты получили бы шанс, если при их ведении это можно было бы учесть.
К сожалению, большинство из нас склонны к простым решениям, это в нашей природе. Именно поэтому так популярна идея, что использование определённой методологии или подхода к ведению проектов может решить все возникающие в них проблемы. Многие из моих коллег наверняка помнят огромные буквы AGILE на входе в центральный офис Сбербанка. Но следование нескольким простым правилам никогда не являлось панацеей, ни в том, чтобы за месяц стать стройным и красивым, ни в том, чтобы реализовать сложный проект в рамках запланированного бюджета и с нужным качеством.
Почему невозможно точно оценить проект
Вероятно, самым сложным вопросом в работе над проектами является их оценка. Речь идёт о стоимости и сроках работ. Это проявляется как в самом начале, когда бизнес пытается определить предполагаемый бюджет, так и по ходу, когда расходы на проект начинают расти непредсказуемым образом, а срок завершения работ уезжает куда-то в будущее. Из-за непонимания причин такой ситуации многие проекты обречены с самого начала, хотя попытки найти виновного продолжаются в течение всего периода работы и тем более после. По своему опыту могу утверждать, что не существует в природе ни одного проекта, который избежал подобной участи хотя бы в некоторой степени.
Как я уже написал в самом начале главы, бизнес склонен видеть причину неверной оценки в низкой компетенции привлечённых специалистов. Кажется, что на это есть основания, и профессионалы часто дают для этого повод. Но возможно ли в самом начале проекта, когда о нем
известно меньше всего, спрогнозировать и рассчитать его бюджет и спланировать работы? Не является ли ошибочным само требование сделать подобную оценку?
Начать нужно с объяснения того, в чем состоит уникальное отличие процесса создания цифровых продуктов от обычных услуг, и уж тем более от производства товаров и ещё больше от их продажи. Разница заключается в степени неопределённости. В цифровых проектах она зашкаливающе высока, и просто сказать, что «карта — это не территория, а модель мира — не сам мир», значит не увидеть сути.
Смотрите, когда вы покупаете товар в магазине, то неопределённости нет совсем, вот товар, вот деньги. Если вы занимаетесь производством, то у вас есть технология (карта), дающая определённость в характеристиках будущего товара (территории), сроках его изготовления и требованиях к исходным материалам. Но когда вы создаёте цифровой продукт, есть только ожидания того, как он повлияет на бизнес, и иногда смутные образы того, как будет выглядеть его интерфейс. Не вносит ясности и то, что принято называть техническим заданием, тем более таковым оно обычно не
является. Все, что произойдёт дальше в проекте, будет зависеть от людей, в нем участвующих, и от их способности разобраться, что же нужно получить в итоге. Создание нового продукта — это создание одновременно и карты (представление о будущем продукте, проектная документация, дизайн, программный код), и территории (готовый продукт).
Думаю, вы уже хотите поспорить со мной, сказав, что раз все так плохо, то почему в принципе существуют цифровые технологии и бизнесы, их использующие. Вероятно, вы также хотите сказать, что проектная команда, получив требования к будущему продукту, может воспользоваться своими наработками из предыдущих проектов и в целом опытом индустрии. Все так. Но, во-первых, откуда вы знаете, какую цену пришлось заплатить бизнесу за работающие продукты и сколько проектов при этом не получилось, а во-вторых, действительно ли они заказывали именно то, что получили в итоге. Неявные различия даже в похожих между собой проектах могут быть очень большие, а способов решить одну и ту же задачу у программистов и дизайнеров ещё больше.
Задумайтесь на минуту. При проектировании и разработке каждый специалист принимает тысячи решений. Это касается набора функций, интерфейса, технической архитектуры, выбора библиотек и стиля программирования, схем интеграции с внешними сервисами и сценариев взаимодействия с пользователями. Не существует единственного варианта решения той или иной задачи.
Кроме того, решения взаимосвязаны между собой и влияют друг на друга. К этому нужно добавить то, что по мере движения от первоначальных требований к готовому продукту в зависимости от принятых решений возникают новые задачи и вопросы, подобно ветвям и листьям растущего дерева, и предсказать заранее их невозможно. В результате каждый проект представляет собой уникальное сочетание навыков конкретных специалистов, случайностей и озарений, лени и личных проблем, влияния мнений окружающих людей и особенностей взаимоотношений в проектной команде, ограничений по времени, бюджету и требований со стороны бизнеса.
Вы все ещё думаете, что можно точно спланировать
проект, зафиксировать его стоимость и определить дату его завершения? Я прихожу к выводу, что в мире не существует подхода или методологии, гарантирующих получение нужного вам цифрового продукта. В своё время Миша Токовинин, основатель AmoCRM, сказал, что все споры о методологиях разработки программных продуктов сводятся к обсуждению оптимальной длины итераций в проектах. В одних случаях продукт реализуется в рамках одной длинной итерации, а в других, как в случае со Скрамом, за несколько, но коротких и фиксированных по длительности. Я же утверждаю, что вопрос стоит иначе, и ключевым моментом является то, кто заплатит за риск в проекте, который возникает в силу высокой степени неопределённости, присущей этому виду деятельности.
Бизнес традиционно настаивает на том, что раз уж ИТ-специалисты лучше разбираются в вопросах создания цифровых продуктов, то они и должны отвечать за все параметры проекта. При таком подходе компания, которой заказали разработку продукта, в случае возникновения каких-либо проблем должна решить их за свой счёт. Задача же бизнеса — описать требования к
будущему продукту и оплатить работы по их созданию. Но только если итоговый продукт будет соответствовать изначальным требованиям. Единственным исключением, при котором бизнес готов увеличить бюджет, является изменение первоначальных требований. Хотя, как показывает практика, часто и это служит предметом спора сторон, т.к. любые изменения можно трактовать как новые требования, так и уточнения существующих.
Поскольку никто на корпоративном и законодательном уровне не делает различий между традиционными услугами, поставкой товаров и созданием цифровых продуктов и сервисов, то именно так строится модель привлечения подрядчиков через конкурсы и тендеры. Ошибочной тут является сама идея о том, что возможно в самом начале проекта, в момент, когда в руках у специалистов находится минимум информации, спрогнозировать параметры будущего проекта. Чтобы у них появилась хоть какая-то ясность, нужно пройти достаточно долгий путь, и он точно не укладывается в границы предпроектного обследования, как многим кажется. Здесь важно вспомнить закон Галла,
утверждающий, что «любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все эти связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».
Компании, занимающиеся разработкой цифровых продуктов на заказ, по понятным причинам стараются избегать вменяемой им ответственности. То же самое относится и к ИТ-специалистам, работающим внутри бизнеса. Наиболее популярный приём для переноса рисков на бизнес — продавать не результат, а процесс. Коротко модель можно описать так: мы, специалисты, обладающие известными компетенциями в дизайне, проектировании, разработке, продаём вам своё рабочее время, а на вас, бизнесе, лежит ответственность за то, как вы этим временем и нашими профессиональными навыками воспользуетесь. Если в результате работы получится что-то не то, что вам было нужно, что ж, значит,
вы неправильно нами управляли или хотели чего-то заведомо ошибочного. Но счета за потраченное нами время должны быть оплачены в любом случае.
Когда на стороне бизнеса есть компетентные в проектном управлении люди, подобная модель действительно позволяет бизнесу быстро сформировать команду из необходимых специалистов, фактически арендовать их на время проекта. Но в остальных случаях подрядчикам приходится идти на известные ухищрения, например, предлагая бизнесу работу над проектом по гибкой методологии.
При этом команда специалистов рассматривается как единый механизм, имеющий в своём составе нужный набор компетенций (как правило, не меняющийся от проекта к проекту) и действующий в соответствии с текущими запросами бизнеса. Это подаётся как преимущество, дескать, ты клиент, сам определяешь в каком направлении развиваться продукту, вовремя уточняя требования и выставляя приоритеты. И проект движется как движется, и «все будет готово, когда будет готово». Вам что-то не нравится, и вы хотите ясности? Похоже, вы ретроград и не следите за трендами, сейчас все эджайл!
Не обманывайтесь. Этой истории уже несколько десятков лет. Борьба идёт с переменным успехом, и периодически верх берет то одна, то другая сторона. Благодаря ей на свет регулярно появляются новые методологии и подходы. Дизайн-мышление, проектирование на основе персонажей, Jobs-to-be-done, Agile, Scrum, RUP, экстремальное программирование и т.д.
Каждая новая модель предполагает радикальное улучшение процесса и возможность наконец-таки получать по итогу проекта именно то, что требуется. Но, как говорил Брукс в своей знаменитой книге «Мифический человеко-месяц», серебряной пули как не было, так и нет. И вряд ли она когда-нибудь появится. Методологии в основном служат не снижению неопределённости, а только лишь обосновывают перенос рисков со специалистов на бизнес.
Независимо от того, какой подход используется и на ком, бизнесе или специалистах, лежит ответственность, источник риска, т.е. неопределённость при работе над проектами, не исчезает. В целом от проблемы не может спасти и компромисс между сторонами, т.к. в конечном
счёте кто-то все равно должен заплатить за возникающие издержки, хоть одна, хоть другая, хоть обе стороны.
На вопрос можно посмотреть и по-другому, сказав, что ошибочна сама идея о возможности определить в самом начале проекта его стоимость и сроки реализации. И в этом случае тот факт, что проекты все время выходят за запланированные границы, объясняется вовсе не низкой компетенцией специалистов, а принципиальной невозможностью эти границы спрогнозировать. Не понимая этого, кстати, компании, занимающиеся разработкой продуктов, склонны делать оценку проектов по формуле x2 или x3, т.е. закладывать в бюджет двойную или даже тройную наценку за риски. Но кто может сказать, что такое x1?
Источник: paranoidmethod.org
