Достаточно хорошо.
Не стремитесь все сделать идеально. Не разбазаривайте ограниченные ресурсы на то, что дает 0,2% от результата. Сделайте достаточно хорошо и переходите к следующей задаче. Не страдайте перфекционизмом и идеализмом. Если вы будете вечно допиливать проект – он может стать неактуальном при релизе. Сделайте так, чтобы заказчик был доволен, и этого достаточно. Конечно, бывают случаи, когда надо доводить до блеска (WOW эффект или компонент общего пользования), но в общем случае, опасайтесь идеализма.
Контроль.
Чтобы проект двигался, нужен постоянный контроль. Без него все начинает рассыпаться. Контроль, на мой взгляд, самое сложное место в проекте. И ему надо уделить внимание по максимуму. Создайте свою систему отчетности, сделайте ее простой. Понимание того, что происходит сейчас на проекте, дает вам возможность принимать правильные управленческие решения.
Итерации.
Всегда реализуйте проект итеративно. Сначала вы делаете общий набросок картины. Затем прорисовывайте крупные общие линии. Затем детализируете каждый нюанс на картинке. После каждой итерации у вас должно быть вполне работающее приложение с ограниченным функционалом. Другая аналогия – это телескоп. Вы смотрите на небо через телескоп. Сначала оно размытое, ничего не видно, но в целом пятно вы видите. Затем вы настраиваете четкость, и звезды понемногу начинают проясняться. Также мы доводим проект по итерациям до ясного состояния, когда ясно прорисована каждая деталь.
Это основные принципы, и они наиболее приоритетны на проекте.
Дополнительные принципы
Активное участие заказчика.
Если заказчик не принимает участие в проекте, то риски его провалить очень велики. Обязательно привлекайте заказчика к активному участию. Задавайте вопросы по проекту, давайте ему соответствующие задачи, обсуждайте свои решения на проекте. Очень плохая идея забыть заказчика на месяц – другой и затем представить готовое решение. В этом случае готовьтесь к масштабным доработкам и значительному выходу за бюджет.
Все течет, все меняется.
Не думайте, что единожды определив требования в техническом задании, они не будут меняться. Готовьтесь сразу к тому, что требования могут быть очень сильно изменены. Это нормальная ситуация. Просто сделайте перерасчет бюджета и реализуйте то, что нужно клиенту. Помните о параметрах проекта: объем, качество, сроки, бюджет. Вы можете изменять один параметр за счет других. Например, если вам нужно урезать бюджет проекта, вы можете сделать попроще (качество), либо отказаться от каких-либо функций (объем).
Правильная коммуникация.
Хорошая коммуникация очень упрощает взаимодействие на проекте и, следовательно, снижает его стоимость. Во-первых, старайтесь говорить с клиентом на одном языке. Все умеют пользоваться браузером, вот и говорите с ним о кнопочках, списках и т.д. В этом сильно помогает использование средств макетирования. Следующий момент – никаких истерик и претензий. Это очень напрягает всех участников проекта. Таких людей начинают избегать, от чего они еще больше начинают истерить. Поэтому старайтесь быть максимально корректными по отношению к своим партнерам по проекту. И последний момент – будьте доступными для коммуникации в разумных пределах. Особенно это касается менеджера проекта. Его задача – обеспечить всех необходимыми ресурсами и координировать деятельность. Он должен быть максимально доступен для заказчика и исполнителей. При этом обратный момент – не садитесь на уши. Особенно это касается клиентов, которые садятся на уши менеджеру и менеджеру, который садится на уши исполнителям. Постарайтесь выработать свой ритм взаимодействия по проекту. Все моменты лучше обсуждать за один раз, а не созваниваться по 5 раз за 2 часа. Составьте список всего что нужно обсудить и обсудите это за 1 раз.
Принцип жонглера.
Это скорее относится к менеджерам, которые ведут несколько проектов. Жонглер управляет несколькими шарами одновременно, но в конкретный момент времени в его руках лежит только один шарик. Так же и менеджер в конкретный момент времени должен управлять только одним проектом, не отвлекаясь на другие. Сделайте по максимуму на одном проекте: загрузите всех задачами, делегируйте задачи помощникам, сделайте все, что только можно на проекте, упритесь в какое-то обстоятельство (например, ждем ответа от клиента, или ждем выполнения задачи исполнителем), – и переходите на следующий проект. Работая по такой схеме, вы будете гораздо больше успевать.
Распределенность команды.
Мы изначально исходим из того, что все разработчики будут работать удаленно. Все процессы мы строим исходя из этого принципа. У нас есть офис, но там нет ни одного разработчика. Самое важное для продуктивной работы разработчика – чтобы его поменьше беспокоили. В этом плане удаленная работа как нельзя лучше для этого подходит. Конечно, далеко не каждый сможет работать в таком режиме (кому-то нужен надзиратель за спиной), но такие люди и не задерживаются у нас надолго. Весь контроль строится на основании метрик и задач. Если человек выдает нужный результат, то нет смысла его унижать дополнительным контролем и ограничивать его свободу.
Дублирование.
В веб-разработке есть такой принцип – дублировать код плохо. В ведении проекта все наоборот: дублирование – это хорошо. Вы должны подстраховываться и иметь запасные варианты в случае, если будут проблемы с основными действующими лицами на проекте. Не должно быть такого, что кто-то один на проекте знает то, что другие совсем не в курсе и не представляют как это работает. Обязательно распространяйте знания между разработчиками, чтобы была хотя бы частичная взаимозаменяемость.
Видение бизнеса клиента.
Вы должны видеть дальше, чем просто создать сайт. Сайт нужен для чего-то, а не просто сам по себе. Смотрите глубже. Предугадывайте потребности клиента. Учите программистов и помощника видеть дальше, чем просто разработку очередного модуля.
Прозрачность.
Будьте максимально прозрачными для участников проекта. Когда вы работаете (время для звонков и взаимодействия), какие соглашения используете на проекте, отчетность и т.д. Чем более предсказуемыми вы будете для партнеров, тем лучше.