Сроки и этапы реализации проекта

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

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

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

Почему значительная часть проектов продолжает терпеть неудачу даже при возрастающей сосредоточенности на качестве управления проектами и увеличении числа опытных и компетентных руководителей проектов?

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

По мнению А. Головина, проект потерпит неудачу в трех случаях :

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

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

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

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

В целом следует отметить, что главными причинами неудач проектов являются:

  • Требования: Неясные, отсутствие взаимопонимания, отсутствие приоритетов, противоречивые, двусмысленные, неточные.
  • Ресурсы: Недостаток ресурсов, конфликты за ресурсы, текучка ключевых ресурсов, плохое планирование.
  • Сроки: Слишком сжатые, нереалистичные, слишком оптимистичные.
  • Планирование: основано на недостаточных данных, не все учтено, недостаточно деталей, ошибочные расчеты.
  • Риски: Не идентифицированные или выдуманные, отсутствие управления.

Группа Стэндиш уверена, что самые важные факторы успеха или неудачи проекта таковы, в порядке важности :

  • Степень вовлеченности заказчика.
  • Поддержка высшего руководства.
  • Опытный руководитель проекта.

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

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

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

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

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

Обобщение практического опыта управления проектами показывает, что чаще всего шаги, направленные на спасение проекта, это :

  • модернизация коммуникации и управления (62%);
  • пересмотр задач проекта — сокращение его масштабов, пересмотр финансирования (60%);
  • добавление или удаление ресурсов (58%);
  • решение технических проблем (49%);
  • замена менеджера проекта или привлечение консультанта (36%).

Фирмы, у которых нет методологии, чаще предпочитают заменять менеджера проекта, чем те, у которых методология освоена (22% и 9% соответственно) . Они также чаще привлекают сторонних консультантов для спасения проекта (26% против 11%).

Обычно операции по спасению проблемного проекта довольно успешны. Почти три четверти проблемных проектов (74%) в итоге успешно завершены, 18% еще в процессе, поэтому окончательные результаты не известны. Только 4% действительно провалены, и 3% закрыты из бизнес-соображений.

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

Компании, у которых не принята стандартная методология ведения проекта, не всегда ценят эти умения и навыки, чем те, у которых такая методология присутствует (78% первых высказались о важности квалификации менеджера проекта и 96% — вторых).

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

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

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

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

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

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

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

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

Среди других факторов успеха проектного управления следует назвать:

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

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

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

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

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

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

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

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

Хотя в управлении проектами используются такие термины как «начало-окончание», терминология далеко не так важна, как содержание: то, каким образом работы связаны друг с другом (какова технология).

Очевидно, что исследование кривой «время/стоимость» до начала проекта позволяет компании принять правильное решение при утверждении расписания проекта.

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

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

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

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

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

В отчете, составленном фирмой McKinsey, консультирующей в области управления, опубликованном в журнале Fortune, подсчитано, что некоторые проекты, завершенные в срок, но вышедшие за рамки сметы, на 140 % прибыльнее, чем если бы они уложились в смету, но опоздали бы на шесть месяцев .

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

  1. Общая готовность к изменениям. В успешных организациях царит философия, основанная на следующих положениях: «век живи — век учись», «не ошибается тот, кто ничего не делает», «нет такой проблемы, с которой мы не смогли бы справиться».
  2. Культура конфликтов. При успешных проектах с конфликтами обходятся конструктивно и открыто. Царит свободный обмен информацией и мнениями, а также открытость для критики.
  3. Личная ответственность сотрудников проекта. Успех проектов непосредственно связан со степенью личной ответственности сотрудников проекта и возможности самоорганизации. Чем большими полномочиями обладает каждый в отдельности, тем скорее он готов взять на себя ответственность, и тем больше его личная инициатива и мотивация. Малые полномочия, напротив, способствуют пассивности и даже противодействию.
  4. Культура доверия. По-человечески приятный климат открытости, искренности и честности в общении друг с другом повышает вероятность успеха проектов. При культуре доверия существует меньшая степень принятия ошибок и решения принимаются всеми, а после решения претворяются в жизнь.
  5. Отсутствие иерархии. Проекты тогда были особенно успешными, когда работа над проектом происходила в команде, где иерархия не играет роли в организации проекта или, по меньшей мере, сведена до минимума. Жесткая иерархия блокировала в неудачных проектах творчество и мотивацию сотрудников проекта.
  6. Коммуникационная и информационная культура. Проекты были особенно успешными, когда в команде царила атмосфера интенсивного обмена информацией и открытой коммуникации, т.е. высокая степень гласности. Хорошая коммуникация в этом отношении означает хорошее сотрудничество, и наоборот. Интенсивная коммуникация между различными функциональными сферами приводит к тому, что растет взаимопонимание, и сотрудники могут взглянуть за «край тарелки» своей собственной сферы, что приводит к принятию более взвешенных решений.

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

Agile

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

Упрощенная схема работы по Agile выглядит так:

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

Преимущества Agile:

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

Недостатки Agıle:

  • Не является методом
  • Необходимость каждый раз составлять новую систему управления на основе принципов подхода Agıle
  • Применение подхода сопряжено с изменениями процедур реализации проекта и базовых ценностей
  • Требует знаний, упорства, больших затрат и административных ресурсов (для облегчения применения подхода принято использовать методы Scrum, Kanban и другие)

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

Scrum

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

Наиболее важные части первыми отбираются для выполнения в спринте (спринты в Scrum – это итерации продолжительностью от 2 до 4 недель). По итогам спринта заказчик получает рабочий инкремент продукта, т.е. готовые к использованию части. Как только один спринт закончен, проектная команда начинает следующий спринт. Продолжительность спринтов всегда одинакова, но команда всегда сама устанавливает ее, оценивая свою производительность и особенности проекта.

Упрощенная схема работы по Scrum такова:

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

Вся процессуальная структура метода вращается вокруг пяти основных встреч:

  • Упорядочивание беклога. Встреча напоминает планирование, рассмотренное нами в первом уроке. Проводить ее нужно в первый день нового спринта. На встрече обсуждается то, что уже удалось сделать по проекту и что еще нужно сделать, и определяются дальнейшие шаги. Инициатор ставит задачи, соответствующие новому этапу. Упорядочивание беклога определяет результативность нового спринта.
  • Планирование спринта. После расстановки приоритетов и определения задач инициатором команда принимает решение о своих действиях на протяжении наступающей итерации и ищет способы достижения поставленной цели. Для этого могут использоваться самые разные инструменты планирования и оценки (важно, чтобы они соответствовали принципам метода). Планировать спринт нужно в самом начале итерации, но по окончании встречи по упорядочиванию беклога.
  • Летучки. Летучки – это ежедневные встречи, проводящиеся в одно и то же время (на них тратиться, как правило, до 15 минут). Члены команды делятся информацией о статусе своей работы и состоянии проекта, однако никакие решения не принимаются и проблемы не обсуждаются (для этого выделяется отдельное время, и устраиваются дополнительные встречи). Летучки нужны лишь для обмена сведениями.
  • Подведение итогов спринта. На этом этапе исследуется и адаптируется созданный продукт. Члены команды делятся своими результатами со всеми заинтересованными лицами. Главной задачей здесь является удостовериться в том, что продукт спринта соответствует целям проекта и ожиданиям участников проекта.
  • Ретроспектива спринта. Этап, проводящийся сразу же после предыдущего, но до того как начнет планироваться новый спринт. Команда определяет степень четкости и слаженности пройденного этапа, исследует появившиеся проблемы в методологии, работе и взаимодействии. Благодаря ретроспективе команда может сделать выводы и повысить эффективность следующего спринта.

Преимущества Scrum:

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

Недостатки Scrum:

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

Многие считают, что метод «Скрам» сложен для внедрения, указывая на необходимость в делегировании полномочий, необычную организационную структуру и т.п., однако при умелом использовании и благодаря своей гибкости метод не позволит работе пойти в неверном направлении. Это существенно отличает Scrum от общих принципов Agile.

Kanban

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

Не менее важно и то, что Kanban позволяет приостановить выполнение одной задачи на каком-либо этапе в случае, если появились иные срочные задачи или изменился приоритет текущей. Незавершенная редакция, подвешенные даты, неопределенная часть функции – для метода «Канбан» это норма.

Упрощенная схема работы по Kanban выглядит так:

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

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

Созданная индивидуально система Kanban может обладать такой гибкостью, какая вам нужна. Но есть все же несколько основ, на которых зиждется вся эта система:

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

Преимущества Kanban:

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

Недостатки Kanban:

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

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

Проверьте свои знания

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


Если вы когда-либо занимались разработкой приложений на заказ, то наверняка знакомы с довольно рутинным процессом расчета стоимости и сроков реализации проекта. И ладно бы, если расчет проекта выполнялся лишь единожды, но зачастую потенциальные заказчики не могут уложиться в бюджет, и начинают на ходу менять требования к продукту:
— Это слишком дорого, что если сделаем без функции Х?
— *делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
— *делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
— *очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?
Стандартные пути упрощения расчетов, такие как установка фиксированной стоимости дня работы сотрудника или компании, как правило ведут к потере точности результатов и все равно не избавляют нас от ручных вычислений.
Но, как и любой другой процесс, характеризующийся словами «рутина”, «точность” и «вычисления”, подобные расчеты скорее всего могут быть автоматизированы. Давайте проверим, действительно ли это так.

Процесс расчетов

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

Шаг 1: Оценка задач

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

  • Каталог товаров
  • Корзина и оплата заказов
  • Новости магазина
  • Контакты

После этого командой разработчиков осуществляется определение временных трудозатрат на реализацию всех перечисленных задач:

Задача UI/UX Back-end Android iOS
Каталог товаров 4 дня 2 дня 3 дня 4 дня
Корзина и оплата заказов 3 дня 5 дней 4 дня 5 дней
Новости магазина 2 дня 2 дня 1 день 2 дня
Контакты 1 день 2 дня 2 дня 3 дня

Шаг 2: Расчет сроков разработки проекта

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

Далее нам следует определить очередность этапов выполнения работ (workflow). Вне зависимости от используемой методологии (agile или waterfall) нам нужно знать в каком порядке нашей командой выполняются различные виды работ. В рассматриваемом нами примере с мобильным приложением порядок мог бы выглядеть следующим образом:

То есть, сначала независимо друг от друга выполняется разработка бэк-энда и пользовательского интерфейса, и при их завершении начинается параллельное программирование приложения под разные платформы. После того, как все этапы будут завершены, проект будет считается выполненным.
Теперь мы располагаем всей необходимой информацией и можем приступить к расчету сроков:
В случае с Waterfall: суммируем количество времени для каждого вида работ (UI/UX, Back-end, etc.), добавляем к ним страховку, и, учитывая их очередность, находим самую длительную последовательность работ, которая, собственно, и представляет общее количество времени, необходимое для реализации проекта.
В случае с Agile: учитывая очередность работ, мы определяем время на реализацию каждой из задач (каталог товаров, новости, etc.), после чего, путем их суммирования и добавления страховки, получаем конечный срок реализации проекта.

Шаг 3: Расчет стоимости разработки проекта

Следующее, что нам следует получить — это себестоимость проекта, которая обычно формируется из двух типов затрат: общих ежемесячных расходов (аренда офиса, оплата серверов, лицензий на ПО, etc.) и зарплат непосредственных исполнителей проекта. Что касается зарплат менеджмента, то они больше подходят к первой категории, так как являются более «пассивной” статьей расходов, и в некоторых случаях они могут быть опциональными (к примеру, если речь идет о небольшой команде фрилансеров).
«Общие ежемесячные расходы” рассчитываются предельно просто: делим их сумму на среднее количество дней в месяце и умножаем на количество календарных дней, необходимых для реализации проекта.
Расчет расходов на зарплаты исполнителей зависит от используемой методологии разработки:
В случае с Waterfall: для каждого сотрудника делим ежемесячную зарплату на среднее количество рабочих дней в месяце и умножаем результат на количество рабочих дней, необходимых для реализации этапа работ, за который он ответственен; в конце суммируем все выплаты.
В случае с Agile: для каждого сотрудника делим зарплату на среднее количество рабочих дней в месяце и умножаем на количество рабочих дней, необходимых для реализации всего проекта, в конце суммируем результаты.
Теперь, зная себестоимость проекта (выплаты исполнителям + общие расходы), мы можем получить конечную стоимость, добавив к ней ещё пару вещей:
1. Прибыль: здесь все довольно просто, мы либо прибавляем желаемый процент от себестоимости проекта, либо добавляем соответствующий пункт к «общим расходам” (если желаем получать фиксированный ежемесячный доход).
2. Налоги: каждый считает их немного по-своему в связи с разнообразием систем налогообложения и способов уклонениях от них. В некоторых случаях можно считать налоги как некоторый усредненный процент от себестоимости проекта с включенной прибылью.
3. Комиссия менеджера по продажам: зависит от ваших условий сотрудничества, если вы выплачиваете процент от сделки, то это процент от суммы себестоимости, прибыли и налогов, и если вы выплачиваете процент от прибыли, то, очевидно, считаете ее как процент от заложенной прибыли, полученной в первом пункте.
Итак, теперь мы располагаем итоговой стоимостью проекта. Но что делать, если клиент, услышав результат, спросит нас: «А что если сделаем без X?”.

Автоматизация вычислений

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

  1. Храним данные на сторонних серверах приложения (SaaS). Быстро и удобно, но требует доверия к владельцам сервиса.
  2. Разворачиваем приложение на собственных серверах. Этот вариант требует трудозатрат на настройку и сопровождение приложения, но позволяет самостоятельно контролировать безопасность данных. Дополнительно можно сделать приложение доступными только из собственной инфраструктуры, но это лишает определенных удобств, таких как возможность обратиться к расчетам с личного телефона за пределами офиса.
  3. Реализация программы для расчетов в виде самостоятельного десктоп-приложения, хранящего все данные в локальном файле. Этот случай не предполагает никакой настройки окружения и позволяет самостоятельно контролировать безопасность данных, жертвуя возможностью предоставления общего доступа к данным.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *