распечатать

Применять на практике!

«Применять на практике» — это концепция управления проектами, разработанная и применяемая в компании QSOFT — лидере на рынке web-интерграции. «Применять на практике» — Первый и единственный подход, ориентированный на заказную разработку it-проектов в условиях российских реалий.

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

Михаил Токовинин, генеральный директор QSOFT

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

Денис Митрофанов, исполнительный директор QSOFT

Почему наша концепция заслуживает внимания?

Наша компания QSOFT прошла путь от самой обыкновенной маленькой веб-студии из 3-х приятелей до одной из 10 лидирующих компаний на рынке всего за 5 лет. Мы долгое время остаемся ведущим партнером компании 1C-Битрикс по внедрению одноименной платформы. Мы работаем с десятками крупнейших и известных компаний, участвуем в крупнейших тендерах на разработку веб-приложений.

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

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

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

Мы уверены, что есть вещи, которые нельзя изменить. Если в теории можно предположить, что есть такой Заказчик и такой проект, где все делается по ТЗ, то на практике вы всегда сталкиваетесь с так называемыми «изменяющимися требованиями». Эти изменения делают проект провальным и нерентабельным. Но если нельзя победить причину проблем, то это не значит, что нельзя справиться с симптомами — научиться мириться с изменениями, управлять ими.

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

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

Если вы откроете почти любую методологию по управлению проектами, то наткнетесь на так называемый итерационный подход, на предложение разбить проект на части и делать его «кусками». Это не удивительно, ведь все сложные продукты, которые нас окружают, по сути развивались итерационно, совершенствуя версию за версией. Человек и сам продукт такой многомиллионной итерации. Но одно дело теория, а как ее применять на практике, в случае с веб-проектами?

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

Не пытайтесь детально разобраться в каждой задаче. Уделите больше внимание тому, что предстоит делать сначала, ведь после требования могут измениться, могут появится новые требования. Важно, чтобы список задач был полным, и все участники проекта (Заказчик, исполнитель) понимали, что выполнение всех задач из списка — это и есть завершение проекта.

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

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

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

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

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

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

В своей концепции «Применять на практике» мы рекомендуем свести к минимуму стратегическое планирование и сконцентрироваться на операционном управлении.

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

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

Если выполняется 80% недельного плана (недельной итерации) — это хороший результат. Если же по итогам недели выясняется, что из запланированного решено только 20% задач, а остальное время выполнялись внеплановые задачи, то вам нужно лучше проводить планерки.

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

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

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

Проектирование нужно начинать с наиболее сложного и критичного для бизнеса Заказчика функционала. Эта часть должна быть раскрыта максимально подробно.

Делите процесс на анализ и проектирование. На фазе анализа нужно описать, ЧТО делает система (т.е. внешнее поведение), а уже после утверждения внешнего поведения, не меняя его, спроектировать КАК будет работать система.

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

Конечно, ориентация на интерфейсы вовсе не означает, что проектирования делать не нужно вообще. Но мы делаем так: на фазе анализа и обсуждения требований с заказчиком - интерфейсы, а на фазе проектирования - модель БД, классы и т.д.

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

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

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

Если вы не будете прятаться от Заказчика, а будете работать с ним вместе, вы обнаружите целый ряд преимуществ:

  • четкое понимание текущего состояния проекта и отклонение от планов. И вы и Заказчик понимание, что осталось сделать для сдачи этапа работ.
  • значительное уменьшение эффекта 20/80 (когда на последние 20% надо 80% ресурсов). Когда в самом конце проекта выясняется, что все задачи «потрогали», но до конца не довели. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия.
  • соответствие ожиданий Заказчика и реальных результатов ,и как следствие, хорошие отношения с Заказчиком
  • актуальное состояние требований. Заказчик еженедельно принимает работы, а значит уточняет свои требования.

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

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

Но с Заказчиком общается менеджер. Именно менеджер получает от Заказчика требования, дает обещания и несет перед ним персональную моральную ответственность. Пусть менеджер отвечает за весь проект, решили мы.

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

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

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

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

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

Да, возможно, менеджеру потребуется больше времени тратить на проект, на проверку результата. Но это хорошо. Заказчик будет доволен.

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

Что считать успешным проектом? Сам результат? Соответствие его первоначальным договоренностям? Нам кажется, что есть только один объективный критерий для оценки успешности проекта — довольный Заказчик.

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

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

Успешный проект — это когда Заказчик и другие заинтересованные лица (в том числе разработчики) остались довольны.

И заметьте, никто не говорит о сроках, бюджете или ТЗ.

Когда мы начинаем говорить об изменяющихся требованиях, о проблемах, которые они вызывают, нам кажется, что надо во что бы то ни стало с этим бороться. На практике же оказывается, что мы ничего не можем с этим поделать. Заказчик всегда просит что-то еще, сверх того, что было написано и утверждено до этого. И в чем проблема, спросили бы мы Вас? Проблема не в том, что Заказчик попросил что-то еще, а в том, что Вы были к этому не готовы, не учли это в своих расчетах, не заложили в бюджет или обещанные сроки.

Так почему бы это не учесть с самого начала? Почему бы при своих оценках не допускать некоторый «зазор»?

Да, мы не можем заложить большой запас, потому что тогда наше предложение будет не конкурентным и не интересным Заказчику, но нам и не надо. Попробуйте при обсуждении с Заказчиком рамок проекта, при определении бюджета и сроков исходить не из того, что будет на проекте, а из того, чего там точно не должно быть. Вы обнаружите, что такой подход позволит Вам достаточно ограничить размеры проекта, чтобы запаса в 10 — 20 % хватало почти на все «хотелки» Заказчика.

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

Итак,

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

Перед внесением любых изменений нужно быть уверенным, что это изменение действительно нужно и сделает проект лучше (это можно и нужно обсуждать с заказчиком)

  • Изменения следует вносить только после отладки и сдачи приемки функционала по ТЗ
  • Естественно, процесс должен быть итерационным, пока итерация не выполнена, в нее нельзя вносить изменения. Пакет изменений оформляется в отдельную итерацию.
  • Чтобы процесс был подконтрольным, и заказчик вносил только действительно важные изменения, мы даем пул часов (например, 100) свободного назначения, которые заказчик может тратить. Естественно, обсуждая с заказчиком внесение тех или иных изменений, ему нужно объяснять, сколько это займет времени и сколько часов у него осталось.

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

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

Подчеркну, что наша цель — создание качественного продукта и предоставление качественного сервиса в процессе его создания.

Если упрощенно, есть 2 типа клиентов:

  • тип 1. важнее результат, готовы идти на компромиссы в процессе
  • тип 2. важнее процесс, результат не определяет успех проекта

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

Но вот что надо иметь ввиду:
  • есть типу 1 создать отличный сервис в процессе, но не сделать продукт качественно и в срок, то заказчик будет недоволен
  • если типу 2 сделать хороший продукт, но с плохим сервисом, то заказчик будет недоволен.

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

Спасибо, что прочитали до конца. Надеемся, что "Применять на практике" окажется для вас полезной информацией.

p.s. поскольку у нас всего одна страница и на одного посетителя приходится один хит, единственный способ оценить заинтересовал вас материал или нет, было подглядеть, сколько закладок вы откроете.