Организация работы сотрудников

Организация работы сотрудников

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

Организация работы сотрудников

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *