Управление проектом разработки сайта или веб-приложения. От идеи до внедрения

Руслан Раянов

Управление проектом разработки сайта или веб-приложения

От идеи до внедрения

www.web-automation.ru 2015

Введение

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

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

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

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

После прочтения книги у вас будет представление о том:

● что такое проект

● что такое принципы эффективности

● как вести проект

● как управлять ресурсами на проекте

● как планировать проект

● как решать проблемы

● как вести ежедневную текучку по проектам

● как делать отчеты по проектам

● как организовать взаимодействие с заказчиком и исполнителями

Сейчас есть довольно большое количество различных методик (agile, scrum и т.д.). Мы не будем рассматривать ведение проекта в контексте какой-либо методологии. Я просто опишу наше видение, как надо вести проекты. Что-то может пересекаться с известными методологиями, что-то – нет. Поэтому при прочтении прошу не сравнивать с другими подходами ведения проекта.

Какие проекты мы будем рассматривать в книге?

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

Другой момент, мы не рассматриваем большие проекты со стоимостью выше 1-2 млн. рублей. У меня нет опыта разработки подобных проектов и думаю там есть значительные отличия. В первую очередь в том, что надо учитывать значительно больше интересов разных сторон. Важный момент – при увеличении размера проекта сложность его ведения увеличивается непропорционально. Т.е., чем больше объектов задействовано в проекте, тем сложнее всем этим управлять, и зависимость сложности от количества нелинейная.

Возможно, те, кто далек от мира разработки сайтов и веб-приложений, сочтут, что это чтиво не для них. Специально для вас, вся наша жизнь – это продвижение от одного проекта к другому: поездка на отдых, уборка квартиры, свидание, устройство на новую работу, открытие своего бизнеса, разработка сайта, – все это проекты. Воспринимайте все, что вы делаете для достижения определенных целей как проекты. Принимая такой контекст, примените эту книгу для достижения своих целей. Мы не будем рассматривать в книге постановку целей (цель в наших проектах – сделать сайт). Вы сами можете их определить и прорабатывать их в соответствии с принципами, заложенными в этой книге. Рекомендую вам начинать с одного проекта – иначе вы рискуете забросить это дело в середине пути, а это самый худший исход проекта.

Итак, давайте начинать. В первой главе мы изучим принципы, на основании которых мы ведем проекты.

Глава 1. Принципы ведения проекта

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

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

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

Здесь я приведу наши принципы работы. В вашем случае они могут быть совсем другие. Вы сами должны определить для себя свои принципы.

Основные принципы ведения проектов

Лучше делать быстро, чем медленно.

Мы всегда стараемся оптимизировать по времени наши действия на проекте. Я бы условно разделил людей на “тугодумов” и “скорострелов”. Так вот мы – “самострелы”. Скорость выполнения для нас – приоритет. Конечно, не всегда это получается, и у нас бывают простои и задержки. Но мы работаем над этим, и скорость выполнения работы очень важна для нас.

Достаточно хорошо.

Не стремитесь все сделать идеально. Не разбазаривайте ограниченные ресурсы на то, что дает 0,2% от результата. Сделайте достаточно хорошо и переходите к следующей задаче. Не страдайте перфекционизмом и идеализмом. Если вы будете вечно допиливать проект – он может стать неактуальном при релизе. Сделайте так, чтобы заказчик был доволен, и этого достаточно. Конечно, бывают случаи, когда надо доводить до блеска (WOW эффект или компонент общего пользования), но в общем случае, опасайтесь идеализма.

Контроль.

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

Итерации.

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

Это основные принципы, и они наиболее приоритетны на проекте.

Дополнительные принципы

Активное участие заказчика.

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

Все течет, все меняется.

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

Правильная коммуникация.

Хорошая коммуникация очень упрощает взаимодействие на проекте и, следовательно, снижает его стоимость. Во-первых, старайтесь говорить с клиентом на одном языке. Все умеют пользоваться браузером, вот и говорите с ним о кнопочках, списках и т.д. В этом сильно помогает использование средств макетирования. Следующий момент – никаких истерик и претензий. Это очень напрягает всех участников проекта. Таких людей начинают избегать, от чего они еще больше начинают истерить. Поэтому старайтесь быть максимально корректными по отношению к своим партнерам по проекту. И последний момент – будьте доступными для коммуникации в разумных пределах. Особенно это касается менеджера проекта. Его задача – обеспечить всех необходимыми ресурсами и координировать деятельность. Он должен быть максимально доступен для заказчика и исполнителей. При этом обратный момент – не садитесь на уши. Особенно это касается клиентов, которые садятся на уши менеджеру и менеджеру, который садится на уши исполнителям. Постарайтесь выработать свой ритм взаимодействия по проекту. Все моменты лучше обсуждать за один раз, а не созваниваться по 5 раз за 2 часа. Составьте список всего что нужно обсудить и обсудите это за 1 раз.

Принцип жонглера.

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

Распределенность команды.

Мы изначально исходим из того, что все разработчики будут работать удаленно. Все процессы мы строим исходя из этого принципа. У нас есть офис, но там нет ни одного разработчика. Самое важное для продуктивной работы разработчика – чтобы его поменьше беспокоили. В этом плане удаленная работа как нельзя лучше для этого подходит. Конечно, далеко не каждый сможет работать в таком режиме (кому-то нужен надзиратель за спиной), но такие люди и не задерживаются у нас надолго. Весь контроль строится на основании метрик и задач. Если человек выдает нужный результат, то нет смысла его унижать дополнительным контролем и ограничивать его свободу.

Дублирование.

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

Видение бизнеса клиента.

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

Прозрачность.

Будьте максимально прозрачными для участников проекта. Когда вы работаете (время для звонков и взаимодействия), какие соглашения используете на проекте, отчетность и т.д. Чем более предсказуемыми вы будете для партнеров, тем лучше.

Проблемы – это нормально.

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

Сервис.

Сервис – это основа всего. Все, что мы делаем – мы делаем для клиента. Именно он платит деньги, а не работодатель. Наша задача – быстро и легко давать клиенту то, что он просит.

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

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

Глава 2. Менеджер проекта и заказчик.

Менеджер проекта – это главный человек на проекте. Именно от него во многом зависит успех. Именно менеджер проекта принимает ключевые решения. Именно менеджер объединяет людей с разными навыками и возможностями для достижения определенной бизнес-цели.

Давайте выделим основные функции, которые выполняет менеджер на проекте:

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

● Взаимодействие с исполнителями. Это постановка задач, пояснение их особенностей, проведение планерок и т.д. Важен постоянный контакт между исполнителями и менеджерами. Менеджер должен знать, как идет выполнение задач и общий моральный климат на проекте. Исполнители также должны чувствовать поддержку менеджера и его активное участие (особенно при удаленном способе работы). Менеджер должен давать адекватную обратную связь исполнителю по его работе и стилю выполнения задач (медленно/быстро, количество ошибок, дедлайны, форма отчета, полнота решения и т.д.).

● Бизнес-аналитика. Очень часто менеджер выполняет эту роль. Он изучает предметную область заказчика, прорабатывает отдельные моменты и выступает внутри команды от имени заказчика в решении вопросов по бизнес-логике. В больших проектах для проработки бизнес-логики выделяется отдельный человек, который занимается только этим (бизнес-аналитик).

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

● Планирование проекта. Менеджер на основании технического задания составляет план итераций и планы по каждой итерации отдельно. Нет смысла прописывать весь план очень подробно. Все равно будут изменения и ваш план будет перекраиваться не раз. Гораздо лучше составить общий примерный план и четко спланировать очередную итерацию (на 1-2 недели).

● Выделение ресурсов. Обычно у менеджера есть набор ресурсов. Это могут быть денежные средства, время, люди, программные средства и т.д. Задача менеджера – грамотно и экономно ими распорядится для достижения цели проекта за минимальное количество шагов.

● Решение проблем. Если возникают какие-то проблемы на проекте, то обычно именно менеджер их разруливает. У него для этого есть все полномочия и права, а также ответственность. Исполнители также должны стараться самостоятельно решать проблемы. Они знают принципы и могут на основании них решать большинство таких моментов. Проблемы на проекте могут быть очень разнообразными, но можно выделить несколько типов:

○ человеческий фактор. Обычно это конфликт между людьми. Изучайте переговоры – это позволит эффективно и взаимовыгодно решать любые вопросы.

○ проблемы с ПО. Что-то не так работает, сбои и т.д.

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

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

Теперь давайте рассмотрим качества, которые присущи хорошему менеджеру:

● Во-первых, он должен понимать и принимать основные принципы разработки и ведения проекта. Менеджер должен быть оплотом этих принципов и борцом за них. Если этого нет – то проект будет сложно продвигаться.

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

● Навыки переговоров. Менеджер – это, в первую очередь, общение. Львиная доля работы менеджера – это общение с клиентами, исполнителями и другими заинтересованными лицами. Это может быть разговор по телефону, живое общение или переписка (email, чат или отчет). В любом случае, если вы хотите быть менеджером, вам надо прокачать навык переговоров и продаж, которые идут рука об руку.

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

● Умение говорить на техническом и бизнес-языке. Вы должны понимать своих клиентов. Обычно они говорят на языке маржи, процентных ставок и т.д. Т.е. они говорят на языке своей предметной области. Разработчики обычно говорят в терминах базы данных, процедур, классов, URL и т.д. Вы должны понимать их терминологию и уметь соотносить бизнес-язык заказчиков с техническим языком разработчиков. Не ставьте задачу исполнителю на бизнес-языке, т.к. возникает большой риск непонимания и последующего неверного решения. Будьте транслятором между этими 2 мирами, а не испорченным телефоном.

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

● Исполнительность. Исполнительность означает, что если вы задумали сделать какое-то дело, то вы его просто ДЕЛАЕТЕ, а не бесконечно его затягиваете, ожидая идеального момента, придумываете сложности и т.д. Этот навык крайне важен для менеджера. Просто берем и делаем. Проблемы с исполнительностью часто бывают у интеллигентных или просто умных людей. Они слишком много думают и мало делают. Сделайте упор именно на Делание, а не Продумывание. В конечном счете именно действия будут определять ваш результат, а не мысли (хотя правильные мысли тоже хорошая штука). Мысли без действия – это как семена без земли. Положив их в коробку, вы никогда не получите урожая.

● Навык принятия решения и ответственность. Ответственность для менеджера должна быть привычным делом. Сила менеджера соотносится с тем, насколько масштабные проблемы он может взять на себя. Принимая любое решение, вы берете на себя его последствия. Никогда не будьте страусом – просто пряча от проблемы голову в песок. Ответственно принимайте решения, основанные на правильных принципах и здравом смысле, и в 95% вы будете правы (5% – бывают фатальные случаи, когда сложно предугадать развитие ситуации).

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

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

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

● Своевременно готовить материалы для сайта – текст, графику и т.д. Если вы хотите, чтобы проект завершился до дедлайна, то в вашей силе этому поспособствовать – оперативно реагируйте на запросы по контенту. Очень часто из-за этого возникают простои. Либо контент меняется по несколько раз, т.к. заказчик недостаточно основательно продумал его с самого начала. Конечно, правки всегда могут быть, но их не должно быть очень много – это тормозит команду разработки (конечно, в идеальном случае это вообще не должно пересекаться – разработка и наполнение контентом, но в реальных условиях это довольно частая практика. Еще момент в пользу такого подхода – заказчик неявно начинает тестировать сайт на реальных данных).

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

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