Что такое планирование проекта
Планирование проекта: методы и этапы
Сущность проектирования заключается в выработке стратегии достижения определенных целей. Создается модель, в соответствии с которой поэтапно реализуются те или иные действия, приближающие к конечному результату. Но и планирование проекта как таковое нуждается в тщательном анализе и проработке, чтобы стратегия решения поставленной задачи предполагала использование оптимальных средств и способов, которые повысят шансы на успешность в достижении целей.
Понятие и цель планирования
Еще до начала непосредственного проектирования формируется концепция, принципы и модель, по которой будет разрабатываться план действий. Это основа, на которой строится система целенаправленных шагов, ориентированных на достижение результата. Под результатом понимается конечная цель, ради которой и разрабатывается проектное решение. Изначально создается каркас организационной структуры, в рамках которой утверждается порядок, последовательность и характер выполнения работ. Также ставятся задачи планирования проекта, в которых может раскрываться и тактика использования материально-технических ресурсов. Непосредственно планирование охватывает все фазы создания проектного решения, но это не значит, что они должны разрабатываться по единой модели. На каждой стадии может применяться индивидуальный подход, учитывающий специфику рабочих действий и сложности их выполнения. Однако этапы проекта должны быть структурированы в общей системе планирования.
Модель, по которой будет разрабатываться проект, в любом случае строится с акцентом на достижение конечного результата. Только в этом случае можно будет рассчитывать на создание оптимальной по качеству стратегии управления. Важную роль играют и вводные данные, которые могут вводить правила, принципы или ограничения, значимость которых проявится уже после осуществления проекта. На данный же момент следует определить цель планирования проекта, которая будет заключаться в создании оптимальной модели действий с точки зрения реализации поставленной задачи.
Планирование предметной области
Один из начальных этапов планирования, в ходе которого определяется часть основополагающих параметров проекта. Под предметной областью в данном случае понимается совокупность целей и задач, достижение которых должно быть реализовано в процессе завершения проекта. Причем если конкретные направления пошагового движения к цели ставят вполне определенные точки достижения по измеряемым параметрам, то предметная область определяется как более широкая инфраструктура конечной цели. Она может затрагивать и факторы, которые проявятся уже в ходе эксплуатации продукта или выработанного технологического решения. Что конкретно на начальном этапе может дать планирование проекта с учетом предметной области? Данная модель позволяет выполнить следующие задачи:
Состав процессов планирования
По мере разработки плана его создатели переходят от общего формулирования и технического обоснования целей к детальному описанию мероприятий, которые нужно будет выполнить для достижения конкретных целей. И опять же, нельзя рассматривать систему формирования организационной структуры плана как замкнутую даже после интеграции вводных данных. Даже без внешнего поступления новой информации может возникнуть потребность в дополнительных сведениях или уточнении прежних данных. По этой же причине процессы планирования проекта обладают свойством цикличности. Повторение необходимо для производства операции с учетом обновленных данных.
В то же время каждая итерация изначально должна иметь четкую последовательность выполнения – и по отдельным стадиям, и в рамках общей планировочной модели. К конкретным процессам можно отнести следующие:
В зависимости от сложности исполнения, система планирования проекта может включать и разные наборы вспомогательных процессов. К наиболее распространенным среди них относят разработку стандартов контроля и качества, определение статусов подчиненности и ответственности, подготовку требуемых средств информации и коммуникации. Также в ходе планирования могут возникнуть потребности в новых процессах, не предусмотренных на этапе формулирования целей и задач.
Этапы создания календарного плана
Независимо от выбранной тактики планирования, управляющему отделу нужно будет разрабатывать структуру с содержанием работ, указанием рисков и ограничений. Но определить конкретную модель движения к цели не удастся без календарного планирования проекта, которое состоит из следующих этапов:
В данной структуре плана стоит выделить этапы, связанные с рисками и ограничениями. Качество планирования управления проектом будет зависеть от изначально утвержденных способов реагирования на те или иные факторы. В частности, существует два способа реагирования – активное и пассивное. В первом случае в проект закладывается тактика действий, минимизирующих саму вероятность проявления рисков. Пассивное стратегическое реагирование основывается на допущении рисков, а также компенсации условного ущерба от последствий их реализации.
Методы разработки планов
Создание стратегии управления допускает применение четырех способов разработки, каждый из которых может применяться на нескольких этапах планирования проекта
Особенности ресурсного планирования
Материально-техническое, информационное и организационное обеспечение в процессах подготовки и реализации проектов имеют большое значение. Они в значительной степени определяют конфигурации и последовательности выполнения отдельных этапов и операций на пути к достижению как основных, так и промежуточных задач. Поэтому стоит отдельно рассмотреть метод планирования проектов с позиции распределения ресурсной базы. Итак, в основу структурной разработки данной модели планирования ляжет классификация ресурсов по исчерпаемости. Сразу надо определиться, что те же материально-технические средства могут полностью или частично отдаваться на реализацию отдельного этапа. Здесь же будет влиять и принцип рационального расхода и перераспределения ресурсов, при котором грамотное планирование позволит эффективно потреблять, к примеру, топливо на одних участках, и экономить его на других.
Существенным фактором ресурсного планирования проекта является и потребность, которая определяется через интенсивность затрат. Рабочая фаза будет зависеть от объемов потраченного сырья. Как результат, вместе с продолжительностью времени выполнения той или иной операции будет указываться и величина требуемой ресурсной основы. Разумеется, в зависимости от характера задачи на одну операцию может уходить несколько видов ресурсов.
Планирование этапов реализации проекта
Задействуется группа управляющих процессов, которая замыкает планирование, оставляя дополнительные материалы и руководства по выполнению проекта. В этой части учитываются факторы координации, оперативности реагирования и лидерские качества исполнителя или команды исполнителей. Итак, планирование реализации проекта предусматривает разработку следующих этапов:
Планирование рисков проекта
Уже говорилось о важности предварительного создания модели реагирования на риски. Конкретная модель их обработки может строиться на следующих ответных механизмах:
Распространенные ошибки планирования
Многие просчеты в тех или иных факторах и параметрах создания плана могут проявиться только в процессе эксплуатации проектируемого продукта или решения. Но есть и модельные ошибки, с которыми лучше соотносить подготовленные проектные материалы заранее:
Заключение
Видение образа самой структуры плана выполнения действий, которые приближают к конечной цели, весьма значимо для участников проектировочных процессов. Это позволяет учитывать весь спектр нюансов и факторов, которые в той или иной степени влияют на ход работы. Поэтому в стратегическое планирование проектов закладывается ресурс на подготовку концепции дальнейшей разработки. Как минимум формулируются принципы реализации поставленных задач. Только при таком подходе можно рассчитывать на успешное достижение и конечных целей. Кроме того, глубокий планировочный анализ дает возможность и существенной оптимизации проекта, что выгодно и с экономической точки зрения для заказчика.
Управление проектами: планирование
Менеджер управляет проектами – а этого никак нельзя сделать, если нет никакого понимания, когда что должно произойти по ходу выполнения проекта. Для того, чтобы понимание было, мы занимаемся планированием – тема сегодняшней статьи.
Представь себе, что тебе нужно построить тот же дом. Представь, что каким-то образом ты пропустил этап “планирование” и сразу начал строить. И вот ты берешь кирпичи, кладешь их друг на друга, потом понимаешь, что не рассчитал по финансам, и эту стройку закончить не можешь. Берешь кредит, продолжаешь строительство. Докладываешь кирпичные стены, кладешь сверху шифер и вдруг оказывается, что без фундамента эта тема долго не простоит (вообще не простоит, на самом деле). Ты ломаешь все, делаешь фундамент, кладешь кирпичи, крышу, а тут вдруг (внезапно!) оказывается, что до ближайших коммуникаций тридцать километров по прямой, и строить здесь дом бессмысленно вовсе. Ну или хотел ты шестикомнатный таунхаус, а получил одноэтажный барак. Можно, конечно, рассказать коллегам, что у тебя там был эджайл и все по плану, но не было там никакого плана. Планирование – та фича, которая должна помочь избежать подобных неожиданностей. Чем четче план – тем меньше шансов, что что-то пойдет не так. Идеально не будет никогда, но с планом жить станет проще.
Планирование – один из основных процессов в управлении проектами. По важности он чуть ли не важнее реализации проекта. Стоит этот процесс сразу за “инициализацией”, когда кто-то кому-то сказал: “проекту быть!”. На деле, та же инициализация тоже планируется, но в меньших масштабах. При планировании проекта мы должны понять, что от нас требуется, когда, что у нас к этому есть, как это влияет на что-то еще и когда мы это сможем вытащить. Планирование – наше все. К планированию относится и управление рисками, о нем я тоже однажды расскажу подробнее – в самом “управлении рисками” есть свой пунктик “планирование”.
Тема применима не только к управлению проектами – она применима даже к собственной жизни. Вот то, как ты расписываешь бюджет на месяц – планирование. То, как ты в гугл-календаре расставляешь даты отпусков – планирование. Когда ты выезжаешь на работу из Подольска к Садовому – тоже планирование (когда выехать, как проехать, на чем ехать). Есть такие люди, которые вот вообще ничего не планируют и летят туда, куда их пнут. Я про них рассказывать не буду, и вы меня не просите.
Есть мнение, что неправильному планированию обязаны 80-90% провалов проектов (по срокам или содержанию, как минимум). Чтобы такого у вас (и у меня) не случалось, в этом блоке поговорим про макро-планирование, когда предмет планирования – целый проект. Я обещал углубиться в предмет с позиции практической – здесь будет с позиции практической. Все через призму менеджера проектов креативного агентства.
При планировании проектов у нас есть несколько основных групп планирования:
Ниже разберем каждый пункт отдельно. Помимо управления рисками – об этом напишу отдельно – сейчас это будут вкрапления в первые три пункта.
Главный документ в жизни проекта креативного агентства – техническое задание. В техническом задании мы расписываем общий набор того, что ожидаем на выходе. Еще технические задания подписывают и показывают потом заказчику в случае чего – мол, смотри, твоих требований в нем не имеется, потому изволь. Технические задания, кстати, пишутся до согласования стоимости проекта – стоимость потом напрямую зависит от содержания техзадания.
Возможности технического задания не ограничены – теоретически, в нем можно прописать не только все этапы, странички и кнопочки, но и то, как эти кнопки себя будут вести и какого цвета у этих страниц будет фон. Предупреждая читателя, ринувшегося срочно писать подробное техническое задание, говорю: все предусмотреть нереально и в перфекционизм особо вдаваться не рекомендую. Если написание технического задания займет полгода, а проект – месяц, то смысла в этом всем никакого нет. Некоторые проекты вообще не требуют технических заданий – включай благоразумие.
Я пишу технические задания только на функциональные вещи. Раздел такой-то, содержание такое-то, внутри происходит это-то. Увы, NDA, и ничего показать не могу, а писать отдельно под статью – не запланировано. Техническое задание должно быть структурировано, написано простым языком, избегать двусмысленностей – как мануал здесь можно брать статью о деловой переписке, правила те же.
В некоторых случаях, ты не сможешь написать техническое задание самостоятельно – от недостатка экспертизы или недостатка времени. В таких случаях подключаются другие ребята – например, сами исполнители, если исполнитель – программист, а речь идет о сложных технических вещах. В некоторых фирмах написанием техдокументации занимается отдельный специально обученный человек – технических писатель. У нас такого нет, плюс это дело мне само по себе нравится. Тебе я тоже рекомендую самостоятельно писать, чтобы люди, которые не будут отвечать за этот проект не наделали беды еще до старта оного. Или проверяй хотя бы.
Удобно писать технические задания в Google Docs, расставляя важные вещи заголовками – все чисто и аккуратно. Можно делиться ссылкой с заинтересованными лицами – они сразу напишут комментариев. Чем четче в техническом задании прописано, как что должно работать – тем меньше проблем возникнет при передаче проектных задач исполнителям. Менеджер налаживает процессы, а случаи, когда исполнитель уточняет у него каждый шаг, мало похоже на процесс. Автор знает о чем говорит, потому что автор, как человек самоуверенный, периодически может пропускать куски в техническом задании – может от ограничений во времени, а может потому что ленив.
Иногда вместо технического задания используется карта проекта – иерархическая структура. Под тип паука, в центре которого – название проекта, а из него исходят остальные задачи, соблюдая вложенность. Такое “техническое задание” сильно ускоряет оценку проекта, но снижает точность оценки – и времени, и содержания.
После того, как у нас есть техническое задание и понимание содержания проекта, задачи передаются в работу. Разумеется, после подписания задания клиентом.
Здесь у нас планирование работ для передачи исполнителем + планирование сроков исполнения задач. Кто-то верно заметил, что управление проектами – разделение большого пласта на поменьше и попытка всунуть их в какие-то сроки. Примерно так все и есть: на куски мы пилим проект, чтобы было проще контролировать выполнение и расставлять их на таймлайне.
Какой-то особой техники резки задач у меня нет – я точно знаю, что задачи не должны сваливаться на голову исполнителя скопом и должны быть расставлены в логической последовательности. Должно быть понимание критического пути – списка задач, без которых проект жить не сможет, задач, вокруг которых выстраивается весь проект.
Методов пилки задач несколько:
В несложных проектах наш друг – расстановка задач по иерархии. В диджитале сложные проекты случаются редко, потому запоминай. Графически такие планирование выливается в в иерархическую структуру работ – ИСР (или WBS). Иерархическая структура работ – один в один “карта проекта” (она же – ментальная карта или “майндмап”), только направлена в одну сторону. Можно иметь ее параллельно техническому заданию, хуже не станет.
PERT (его еще называют “сетевой график”) примерно в тысячу раз сложнее иерархического планирования, он нужен для сложных проектов – в них PERT поможет не допускать рисков, когда что-то сделано не вовремя. Этот метод планирования определяет последовательность решения задач – что следует до, что после. PERT также используется при оценки времени выполнения задач – интересной фишкой в нем является выставление трех сроков каждой задаче – оптимистическое время выполнения, пессимистическое время решение и наиболее вероятное. На основании этих трех оценок вычисляется наиболее вероятное время. Там ниже говорим про планирование времени, поймете почему это интересно и важно.
Критический путь (и метод критического пути) фича именно PERT. Я не использую сетевые графики в работе, но вот критический путь прям в душу запал. Суть его в том, что он определяет самую долгую последовательность задач – тех, которые нельзя подвинуть или избежать. Критический путь определяет минимальное время завершения проекта.
Итого, проект, в котором достаточно иерархической структуры при планировании задач, может выглядеть так:
Удобно при “водопаде”, о котором рассказывал в предыдущей статье. Плюс, такой проект гораздо проще в планировании времени – все понятно при взгляде сверху. Сетевой график используется, когда задач тысяча, и половина из них между собой связана – когда задача, которая должна быть выполнена после этапа Х зависит от задачи Y, не связанной с задачами A, B и C, которые в графике первые. PERT – такой эджайл при планировании, только что результат проекта точно определен, иначе не надо было бы вам этих графиков.
Возвращаясь к простым, линейным проектам, вернемся и к планированию сроков таких проектов. Кажется, лучшее, что было придумано в этой области – диаграмма Гантта. Это такой лист, где у тебя расписаны задачи с одной стороны, а с другой – линейный календарь, на который положены линии, когда эта задача уйдет в реализацию и будет выполнена.
Это тоже расписание проекта – у него может быть меньшая, по сравнению с сетевым графиком, детализация, но даже такая форма отображения таймлайна проекта лучше, чем никакая. Диаграмма Гантта собирается в экселе, на коленке за 5 минут.
Как-то не получилось у меня отдельно рассказать про планирование сроков проекта, расскажу вкратце и внутри блока “планирование расписания”. Сроки выполнения проекта вычисляются людьми, которые будут делать задачи внутри проекта – каждый в рамках своей зоны ответственности. Обычно это выглядит как указать пальцем в небо, и практика показывает, что палец подходит любой – даже вот твой. Планирование сроков выполнения проекта – всегда предсказание: можно угадать, а можно не угадать. Что с этим делать, я не знаю – обещал рассказать про риски, вот оно.
На планирование работы команды ( = выполнения проекта), работающей для внешнего заказчика влияют не только задачи внутри проекта – влияют задачи из параллельных проектов (ибо такого, чтобы кто-то сидел и ждал именно своего проекта, просто не бывает). Если используется PERT – сроки будут плюс-минус релевантными, ибо берется три пальца в небо и после небольшого вычисления выявляется наиболее вероятный палец. На тех проектах, где полезен PERT, вряд ли бывают конфликты между проектами, а те пальцы куда опытнее, чем мой. Быть может этот блок дополнит следующая статья, про микроменеджмент – там будет немного про управление временем.
После того как мы поняли, что нам нужно, что за чем следует и без чего проект жить не сможет, перемещаемся к планированию команды. Хотел сказать, сразу к работе, но как работать, когда работать пока некому.
Планирование команды проекта должно начинаться примерно на этапе инициализации. Чаще всего на этапе планирования задач уже есть кто-то, кто после будет работать с проектом. Например, люди, готовые поделиться экспертным мнением, чтобы ты, менеджер, потом не зафакапил чего-нибудь.
Где-то на Западе менеджер может скрупулезно выбирать членов команды под проект. Выяснять, насколько тот или иной человек подходит под проект, какие у него взаимоотношения с другими членами команды и почему у исполнителя может возникнуть нежелание работать. Для проектов он их как бы нанимает – изнутри компании, или из вне (рекрутинг или фрилансеры). Когда ты станешь менеджером, ты их тоже будешь нанимать. Только что выбора тебе особого не дадут – вот, есть человек, подключай. Это тебе скажет руководитель направления (или тимлид), в котором работает твой коллега.
Команда может планироваться двумя путями: сразу вся – когда на старте определяется, кто подключится к проекту на каждом этапе, или по мере потребности в ресурсах. В идеале, лучше первый вариант – чтобы все перезнакомились и потом показывали, что они там в процессе наделали, с чем следующему придется разбираться. Фактически чаще случается второй вариант – когда этап верстки планируется через два месяца, глупо планировать работу конкретного технолога, он за эти два месяца может переключиться на что угодно – ждать не будет. Еще есть вариант, когда в проекте группа исполнителей с одной ролью – здесь и так все понятно, они почти что один юнит исполнителя, только большой.
Планирование команды проекта (и отдельных ее членов) нужно делать заранее – никогда в нормальной жизни ты не встретишь ситуации, чтобы кто-то тебе понадобился, и вот сразу он, сидит, ждет когда ты его забрифуешь. Запрашивать ресурсы исполнителей нужно хотя бы за пару недель до – чтобы исполнитель тоже смог спланировать свою работу. Закончить ее например, или передать.
В этот блок отлично подошел бы текст про передачу задач исполнителям, но в Алматы уже вечер, а мне завтра на работу пилить, чтобы собрать для вас контент “с полей”. Добавил себе в задачи тему, поговорим о ней, когда коснемся работы с людьми в проекте.
Технология создания плана проекта
Управление проектами представляет собой симбиоз технологии и искусства решения в срок уникальной задачи в рамках выделенного на ее цели бюджета. Чтобы проект был сделан успешно, необходимо достигнуть понимания руководством компании и РМ, как он будет реализовываться, кем, когда и какие именно работы должны быть выполнены. План проекта рассматривается не как один документ, а как целый комплекс документированных решений, которые и отвечают на вышеуказанные вопросы. Представляю вашему вниманию обзорную статью, рассматривающую основы технологии планирования проекта.
Сущность проектного планирования
Планирование проекта предполагает множество взаимосвязанных итераций, итогом которых выступает единый сводный план. Под планом проекта мы будем далее понимать систему намечаемой деятельности, документально оформленной в результате составления. Эта система состоит из связанных особым образом параметров, обеспечивая которые, решается отдельная задача развития. Данные параметры формируются исходя из ряда функциональных зон проектной деятельности:
План – это ключевой элемент системы управления проектами. Если РМ удалось составить детально проработанный комплекс плановых документов, то он вправе ожидать гарантированного получения требуемых результатов на выходе работ. Для этого сроки, ресурсы и другие аспекты должны быть хорошо спланированы. Пока план не разработан, невозможно знать, сколько средств и времени потребуется для выполнения уникальной задачи. Без плана менеджер практически лишен ориентиров соответствия работ целям проекта.
Надо понимать, что планирование не всегда дает в итоге положительные результаты, но отрицательные выводы способны принести не меньшую, а порой и большую пользу. В любом случае, эффективность вложения средств возрастает, а «распыления» заработанной прибыли не происходит. Проектное планирование закладывает основы продуктивной работы и решает следующие прикладные задачи.
Проектное планирование не может быть «подвешено в воздухе». Его предваряет инициация, а выходом данных процессов является собственно исполнение проекта. И мы осознаем ряд важных моментов о том, что планирование:
Укрупненный состав процессов планирования
План проекта отличается от плана управления проектом и соответствующих процессов планирования. Как мы уже определились, в широком смысле под планом мы понимаем заранее намеченную систему деятельности, для которой установлены порядок выполнения, последовательность и сроки работ. В узком смысле план – это документ, который отражает порядок предусмотренных действий и сроки выполнения. План управления проектом есть результат регламентированных процедур (процессов) планирования, в которых управляющее начало берут на себя регулярные, регламентами закрепленные процедуры создания планов как документов.
Планирование мероприятия включает в себя две группы процессов: процессы непосредственной разработки планов и вспомогательные процедуры. Результатом блока разработки является документ, именуемый сводным планом проекта. В его состав входят календарный план, бюджет мероприятия и ряд других документов. Состав и содержание работ, потребные ресурсы для их выполнения определяют последовательность, продолжительность и размер затрат на их производство.
Планирование возможных рисков (выявление, идентификация и оценка) и управление ими влияют не только на разработку календарного плана, но и на бюджетные потребности. Уточнение целей, определение границ уникальной задачи и структурирование команды и ответственности закладывают основы для полноценной работы по планированию проекта. Далее вашему вниманию предлагается модель связей основных процедур рассматриваемых процессов.
Известно, что по стандарту PMI практически в каждом разделе Руководства PMBOK планированию выделяется целый блок. Исходя из представленной выше схемы, это вполне естественно. Наиболее целостно картину управления планированием и создания единого сводного плана демонстрирует раздел PMBOK «Управление интеграцией проекта». Ниже показан локальный блок диаграммы потоков данных разработки плана управления мероприятием.
Представленный выше визуальный блок примечателен рядом обстоятельств. База знаний по управлению проектами, весь наработанный в этом направлении опыт, регламенты имеют существенное значение для успеха планирования. Это в той же мере касается стандартов, ПО, организационных структуры и культуры, методов управления, инфраструктуры и т.д. Устав является ключевым ориентиром для планирования. Данные процессы являются базисом для интеграции в сводный план и в качестве входов для разработки его итоговой версии предлагают:
Этапы разработки календарного плана
Как мы помним, управление проектом строится на «трех китах»: содержании работ, ограничениях и рисках. Если менеджер умеет хорошо работать с этими тремя параметрами, то для него нет нерешаемых задач. Рассмотрим разработку календарного плана с позиции названных трех позиций и разобьем этот процесс на этапы. Первый и второй этапы мы отнесем к содержанию работ.
Третий и четвертый этапы относятся к позициям ограничений, пятый этап – к рискам. Две основы реагирования (активная и пассивная) определяют момент решения и включения его в проектный план. Активное реагирование подразумевает, что мы в календарный план включаем дополнительные работы, направленные на минимизацию рисков. Это может повлиять на сроки выполнения других работ.
Как пример мы можем рассмотреть проект вывода на рынок новой услуги. Допустим, выявлен риск ее невостребованности на рынке. Тогда для минимизации данного риска необходимо провести дополнительное исследование, и эту работу приходится включать в календарный план. Пассивное реагирование подразумевает формирование дополнительных финансовых резервов под выявленные риски. Этапы разработки календарного плана могут быть представлены также и в логической последовательности, представленной далее.
Основные действия по планированию проекта
Для создания сводного плана менеджер проекта реализует серию планировочных итераций. В ходе выполнения процессов планирования формируются важные инструментальные и итоговые документы, которые в совокупности и составляют сводный план. Среди них:
Выше размещена модель процессов планирования проектной задачи. Полный состав процессов вы имеете возможность рассмотреть на схеме. Процессы планирования по методу «бассейновых дорожек» привязаны практически ко всем разделам управления проектами. Многие из указанных в модели процессов получат возможность быть представленными в отдельных статьях нашего сайта. В настоящем материале мы кратко акцентируем внимание на ключевых процедурах планирования.
В настоящей статье мы познакомились с «максимальной комплектацией» процедур и документов, создающих проектный план. В реальной практике, особенно когда проект по масштабам является средним или небольшим, носит регулярный характер, избыточные усилия по планированию часто не требуются. В таких случаях можно ограничиться типовыми планировочными решениями и неполным составом документов. Вместе с тем, без базового документального комплекта в сводном плане вряд ли можно обойтись, и усилия, потраченные на его разработку, окупаются сторицей.