И так, все предварительные вопросы вы себе задали и приняли твердое и окончательное решение запускать проект. Теперь вы в процессе, и впереди вас ждет большая работа и масса интересных задач, которые необходимо будет решить.
В принципе, существует отдельное… направление (не могу сказать наука), изучающее процесс проектного управления, и все что с ним связано. Эти люди составляют свои нормативы, правила и некоторые закономерности. Никого не буду рекламировать, просто скажу, что есть компании, которые на этом специализируются, а интересующиеся, я думаю, найдут их без проблем.
Но знание и опыт, это немного разные вещи, и мне хотелось бы поведать немного о своем опыте работы, и некоторых наблюдениях в процессе разработки автоматизированных систем.
1) Текущий контроль над процессом.
Если вы руководитель проекта, то, скорее всего вы установите определенный график сбора информации о статусе проекта, раз в неделю, например, где постараетесь заслушать каждого члена команды о ходе его работы. Это верный подход, он позволит вам держать под контролем основные вехи.
Но иногда, этого не достаточно. Что бы вжиться в проект и формировать в команде определенный тонус, очень помогает, так сказать: «мягкий» контроль. Спрашивайте своих подопечных о ходе работ за чашкой кофе, на обеде, выслушивайте их размышления, задавайте наводящие вопросы, интересуйтесь идеями, в общем, разговаривайте с людьми. Но главное здесь соблюдать границы и делать это ненавязчиво и с искренней заинтересованностью.
Это поможет заразить команду, они будут чаще думать о задаче и в фоновом режиме решать некоторые вопросы, а вам позволит глубже погрузиться в процесс и прочувствовать его.
Если вы выступаете в роли заказчика или куратора проекта, для которого этот проект действительно важен, то очень рекомендую хотя бы два раза в месяц выделять по 30 – 40 минут вашего времени и разговаривать с руководителем проекта в неформальной обстановке. Тем самым вы решите сразу две проблемы: будете в курсе всех существенных проблем проекта, чем он живет, и что с ним происходит, и поднимите авторитет руководителя и команды проекта, что благотворно повлияет на атмосферу в коллективе. Да и сами вы будете больше доверять результатам, над которым поразмышляете сами.
2) Старайтесь доводить до исполнителя место его работы в проекте.
Не жалейте на это времени, старайтесь подробно описать роль каждого специалиста в проекте и цель его работы. В таком случае он, во-первых, сможет сориентироваться, как лучше сделать свою работу, что бы принимающий мог лучше к ней подобраться, во-вторых, он может предложить иной подход к решению данного вопроса, который вполне вероятно может быть эффективнее.
Это правило избавит вас от массы ошибок и нестыковок в ходе работы, а кроме того, в качестве приятного бонуса, подарит исполнителям чувство причастности и важности их мнения, что тоже крайне полезно.
3) Команда проекта не должна подвергаться критике со стороны.
Это утверждение верно не только в отношении проекта автоматизации, но и в отношении текущей работы в любом подведомственном коллективе. Не позволяйте критиковать работу ваших специалистов третьим лицам, это может нанести серьезный вред всему проекту.
Все люди по разному воспринимают критику, и есть хорошие специалисты, которые остро переживают из-за недовольства своей работой (причем очень часто незаслуженного), и восстановить производительность такого сотрудника потом очень сложно. Поэтому весь негатив внешнего мира вам предстоит взять на себя, а потом уже разбираться с каждым своим подопечным отдельно, исходя из вашего знания психологии конкретного индивидуума.
Здесь важно, что вы знаете, как спросить с человека за его работу, и сделать это так, что бы он эту работу выполнил, а не уволился.
4) Привлечение к работе заказчика и конечных пользователей.
Здесь есть как свои плюсы, так и серьезные минусы. С одной стороны заказчик будет видеть работу, с другой, он будет видеть и ошибки, которые не всегда будут оперативно устраняться.
Кроме того, у пользователей может наступить момент выгорания и потери интереса в процессе очередной проверки данных, и находить все новые, а иногда и старые (что хуже) ошибки.
Лучшим решением будет постановочные демонстрации. Когда вы готовы к вопросам пользователей, видите недочеты, но главное, вы знаете как их поправить. Таким образом, позволяя участникам найти проблемные места, вы можете быстро, в течение 2-3 дней, их устранить.
Этот прием произведет самое благоприятное впечатление на конечных пользователей, и повысит уровень доверия к системе (чем больше органов чувств задействовано в изучении, тем мы сильнее верим), что несомненно пригодится вам в будущем, когда вы будете её внедрять в производство. Но об этом, в следующей статье.
Главное, не стоит путать этот механизм с наложением картинки на нерабочий функционал, проблема обязательно должна устраняться, репутация проекта и ваша, гораздо важнее.
5) Изменение требований к проекту в ходе работы.
Это самое неприятное, что может произойти. Но такое случается достаточно часто. Начинали разработку как модель для внутреннего пользования, а закончили как система управления холдингом. На первый взгляд кажется, что собственно функционал совсем не изменился, тот же порядок, та же методология. Но повышение объема данных всегда вносит свои коррективы. Выплывает множество мелких факторов, например дополнительные реквизиты, подгружаемые из системы-источника, или новый расчетный показатель (еще не опробованный), все это мешает сдать работу в срок и удовлетворить заказчика.
Приходится продумывать новые пути достижения поставленных задач, спорить о решениях, принятых в ходе реализации проекта, менять архитектуру, это отвлекает ресурсы, мешает внедрению, ухудшает обстановку и создает постоянное давление на команду. Очень хорошо было бы этого избегать и настаивать на завершении работ в том виде, которые запланированы, а потом думать, что можно изменить или добавить.
Если избежать не удается, то смело требуйте ресурсы, что бы вам не говорили о том, что это мелочи и их можно исправить без труда, работа не должна страдать, а ваши нервы тем более.
6) Заранее готовьте эталонные значения, к которым стремитесь
Это, пожалуй, один из самых важных советов данного этапа. Цель достижима ровно на столько, насколько вы ее можете измерить, поэтому в процессе работы вы должны иметь ориентир, к которому стремитесь. Именно он, как компас, позволит вам избегать множества ошибок до их трансляции на всю систему.
Каждый шаг, каждый этап старайтесь просчитать заранее, вы должны ожидать результат.
Что немаловажно, этот принцип поможет вам справиться с проблемой предыдущего пункта, когда вам предъявят требование о дополнительном функционале, попросите предоставить эталонные значения, на которые вам нужно выйти. Иногда, в случае если потребность у заказчика не столь велика, вопрос отпадает сам собой.
Подводя итог, хочу отметить, что в ходе работы над проектом самое важное поддерживать рабочий ритм, не падать духом от проблем и не витать в облаках от достижений, больше практицизма в суждениях, последовательности в действиях, и все у вас получится.