Как правильно организовать работу своих сотрудников? Сделать так, чтобы на выходе были качественные результаты, а персонал получал удовольствие от процесса? Как общаться с Заказчиками и кого винить в неудачах? Предлагаем вашему вниманию вторую часть советов от QSOFTдля менеджеров и руководителей всех звеньев (первую часть можно почитать здесь). Все выводы основаны на собственном опыте и представляют большую ценность.
Почти невозможно взять и сделать хорошо с первого раза. Многие из отличных продуктов, которые нас окружают, пришли к этому состоянию путем проб и ошибок. Важно постоянно получать обратную связь, уточнять требования и совершенствовать свой продукт. Именно поэтому лучше идти итерационно — последовательно отгружая улучшения и изменения, версию за версией.
Чтобы для Заказчика не стали неожиданными затраты на исправление ошибок и отладку при внедрении, важно выделять эти работы в отдельный этап — «пуско-наладочных работ» с собственными ресурсами и временными рамками.
Если так получается, что вы не успеваете к промежуточной сдаче работ Заказчику подготовить достаточно качественный результат, то все равно лучше не переносить презентацию. Сдача работ — это не отчетное мероприятие, а возможность проверить, насколько то, что вы делаете, соответствует ожиданиям Заказчика. Поэтому, лучше тщательнее подготовить презентацию, объясниться, но показать Заказчику то, что готово, и убедиться, что вы идете в правильном направлении.
Для любого действия требуется мотивация. Нужно сильно постараться, чтобы довольный пользователь нашел время и оставил на вашем сайте отзыв. Зато возмущенного клиента долго уговаривать не придется. Именно поэтому, при прочих равных негативных отзывов всегда больше.
Нет ничего неприятнее, чем говорить Заказчику, что что-то пошло не так, что, например, сроки запуска срываются. Иногда менеджер пытается уйти от этого разговора, откладывает его и все дальше усугубляет разрыв между реальностью и ожиданиями. На самом деле, такой разговор откладывать нельзя, а чтобы было легче, важно постоянно обсуждать с Заказчиком вероятность реализации этого риска и способ борьбы с этим. Наверняка, вы вместе найдете решение, если не будете с этим затягивать.
Довольно тяжело добиться от программистов, занятых разработкой, высоких стандартов отгрузки изменений и управления изменениями. Дело в том, что разработчик всегда стремится поскорее запустить результаты своей работы. В это трудно поверить, но только разделение разработки и поддержки между разными людьми позволяет обеспечивать высокие требования к отгрузкам, а как следствие, высокие стандарты надежности.
Проектированием системы всегда занимается Заказчик. Роль менеджера или аналитика — достать необходимые знания, задать уточняющие вопросы и правильно систематизировать ответы. Только Заказчик знает, что надо делать, а остальные могут советовать, как.
Чем больше людей, тем больше потребуется времени. Как бы это странно ни звучало, но при организации работы команды из нескольких разработчиков, все больше и больше трудозатрат уходит на коммуникации между участниками, на координацию. При добавлении каждого дополнительного разработчика, производительность труда (выработка на человека) становится меньше. Наиболее эффективны команды из
Иногда менеджер уделяет слишком мало времени на общение с Заказчиком, полагая что тот должен сам проявлять инициативу в работе над проектом. Такой подход может привести к печальным последствиям. Менеджер проекта как никто другой заинтересован в том, чтобы Заказчик понимал суть выполняемых работ, поэтому лучше сэкономить время на общении с программистом, но как следует все обсудить с Заказчиком.
Программирование — это, конечно, творческая деятельность. Важно, чтобы программистам было интересно то, что они делают. Цель менеджера правильно компоновать задачи, перемешивая рутинное с оригинальным.
Как бы вы не старались, у вас не получится все протестировать. Количество сценариев поведения системы настолько велико, что пользователи все равно найдут такие баги, о которых вы и не подозревали.
Надо понимать, что дизайн, а точнее, внешний вид сайта, — это всего лишь часть вашего предложения. Если оно больше ничем не отличается от конкурентов, то, наверное, хороший дизайн будет решающим. Но если ваше предложение уникально, то дизайн может не играть вообще никакой роли.
Неопытные разработчики часто пеняют друг на друга или на технологии. Стоит относиться к этому с пониманием и заметной долей скепсиса. Опытный разработчик скорее примет решение «дописать», чем «переписать с нуля». Впрочем, иногда нужно действительно начать с чистого листа.
Если менеджер уже несколько раз сменил команду разработки, но проблемы остаются, то можно уверенно утверждать, что дело не в разработчиках. Такое же правило действует и в отношениях Заказчик-Подрядчик. Это командная работа, и в проблемах на проекте не может быть виновата только одна сторона.
Иногда менеджеры и команда стараются предугадать развитие проекта на год или два. В большинстве случаев это пустая трата времени и сил. Внешняя среда неоднородна и не всегда предсказуема, реальный опыт использования может существенно изменить взгляды на полученный результат — поэтому, залог эффективного и долгосрочного развития проекта не в тщательном планировании на годы вперед, а в создании такой среды разработки, в которой можно органично менять и переделывать сделанное ранее.
«Сразу умножайте на число Пи». С одной стороны, программирование происходит в условиях недостаточного проектирования, когда постоянно вскрываются какие-то уточнения и детали, которые ранее не прорабатывались. С другой стороны, разработчик обычно очень оптимистичен, т.к. ему кажется, что он все предусмотрел. К сожалению, бороться с этим практически невозможно и приходится просто учитывать это в своих оценках.
По ходу проекта Заказчик всегда не очень доволен хорошим менеджером, потому что тот спорит, гнет свою линию, заставляет Заказчика принимать решения и делать выбор. Плохой же менеджер очень мил, приветлив и всегда со всем согласен.
Обычно, по ходу продвижения задачи вглубь команды, начинает размываться ответственность. Если бизнес-потребитель (Заказчик) сильно переживает из-за какой-то задачи, то менеджер уже переживает чуть меньше, в то время как конечный исполнитель может вообще не чувствовать никакой ответственности за результат. Чем больше звеньев в этой цепи, тем сильнее наблюдается такой эффект, поэтому, если у вас есть возможность сократить какое-то звено или спрямить коммуникации, этим обязательно стоит воспользоваться.
Если что-то в рамках проектирования можно описать картинкой, а не текстом — это всегда предпочтительнее. Чем легче Заказчику, как источнику знания, оценить предлагаемый проект, тем быстрее мы получим знания о реальных требованиях и ожиданиях и уменьшим риски.
Предельная производительность системы определяется по наиболее узкому ее звену. Если вы не успеваете с версткой, то бесполезно торопить программистов. Если менеджер уделяет слишком мало времени, то команда будет заведомо неэффективна. Фокусируйтесь на этих «узких местах», последовательно их устраняя.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.