Заметки на полях. Часть 2
14.07.2014 | Автор: Денис Митрофанов, QSOFT (CEO, совладелец) 
Как правильно организовать работу своих сотрудников? Сделать так, чтобы на выходе были качественные результаты, а персонал получал удовольствие от процесса? Как общаться с Заказчиками и кого винить в неудачах? Предлагаем вашему вниманию вторую часть советов от QSOFTдля менеджеров и руководителей всех звеньев (первую часть можно почитать здесь). Все выводы основаны на собственном опыте и представляют большую ценность.
21Первый блин всегда комом Почти невозможно взять и сделать хорошо с первого раза. Многие из отличных продуктов, которые нас окружают, пришли к этому состоянию путем проб и ошибок. Важно постоянно получать обратную связь, уточнять требования и совершенствовать свой продукт. Именно поэтому лучше идти итерационно — последовательно отгружая улучшения и изменения, версию за версией.
22Работа над ошибками неизбежна Чтобы для Заказчика не стали неожиданными затраты на исправление ошибок и отладку при внедрении, важно выделять эти работы в отдельный этап — «пуско-наладочных работ» с собственными ресурсами и временными рамками.
23Мало — лучше, чем ничего Если так получается, что вы не успеваете к промежуточной сдаче работ Заказчику подготовить достаточно качественный результат, то все равно лучше не переносить презентацию. Сдача работ — это не отчетное мероприятие, а возможность проверить, насколько то, что вы делаете, соответствует ожиданиям Заказчика. Поэтому, лучше тщательнее подготовить презентацию, объясниться, но показать Заказчику то, что готово, и убедиться, что вы идете в правильном направлении.
24Пару слов о мотивации… Для любого действия требуется мотивация. Нужно сильно постараться, чтобы довольный пользователь нашел время и оставил на вашем сайте отзыв. Зато возмущенного клиента долго уговаривать не придется. Именно поэтому, при прочих равных негативных отзывов всегда больше.
25Главное, не молчать Нет ничего неприятнее, чем говорить Заказчику, что что-то пошло не так, что, например, сроки запуска срываются. Иногда менеджер пытается уйти от этого разговора, откладывает его и все дальше усугубляет разрыв между реальностью и ожиданиями. На самом деле, такой разговор откладывать нельзя, а чтобы было легче, важно постоянно обсуждать с Заказчиком вероятность реализации этого риска и способ борьбы с этим. Наверняка, вы вместе найдете решение, если не будете с этим затягивать.
26Разделение обязанностей повышает качество работы Довольно тяжело добиться от программистов, занятых разработкой, высоких стандартов отгрузки изменений и управления изменениями. Дело в том, что разработчик всегда стремится поскорее запустить результаты своей работы. В это трудно поверить, но только разделение разработки и поддержки между разными людьми позволяет обеспечивать высокие требования к отгрузкам, а как следствие, высокие стандарты надежности.
27С Заказчика — идея, с менеджера — совет Проектированием системы всегда занимается Заказчик. Роль менеджера или аналитика — достать необходимые знания, задать уточняющие вопросы и правильно систематизировать ответы. Только Заказчик знает, что надо делать, а остальные могут советовать, как.
28Меньше народа, больше кислорода Чем больше людей, тем больше потребуется времени. Как бы это странно ни звучало, но при организации работы команды из нескольких разработчиков, все больше и больше трудозатрат уходит на коммуникации между участниками, на координацию. При добавлении каждого дополнительного разработчика, производительность труда (выработка на человека) становится меньше. Наиболее эффективны команды из 2–3 разработчиков, а управлять командой из 10 и более программистов крайне тяжело.
29Общение — золото Иногда менеджер уделяет слишком мало времени на общение с Заказчиком, полагая что тот должен сам проявлять инициативу в работе над проектом. Такой подход может привести к печальным последствиям. Менеджер проекта как никто другой заинтересован в том, чтобы Заказчик понимал суть выполняемых работ, поэтому лучше сэкономить время на общении с программистом, но как следует все обсудить с Заказчиком.
30Чередуйте рутину и творчество Программирование — это, конечно, творческая деятельность. Важно, чтобы программистам было интересно то, что они делают. Цель менеджера правильно компоновать задачи, перемешивая рутинное с оригинальным.
31Ошибки будут, смиритесь Как бы вы не старались, у вас не получится все протестировать. Количество сценариев поведения системы настолько велико, что пользователи все равно найдут такие баги, о которых вы и не подозревали.
32В большинстве случаев дизайн не имеет значения Надо понимать, что дизайн, а точнее, внешний вид сайта, — это всего лишь часть вашего предложения. Если оно больше ничем не отличается от конкурентов, то, наверное, хороший дизайн будет решающим. Но если ваше предложение уникально, то дизайн может не играть вообще никакой роли.
33Иногда лучше начать все заново Неопытные разработчики часто пеняют друг на друга или на технологии. Стоит относиться к этому с пониманием и заметной долей скепсиса. Опытный разработчик скорее примет решение «дописать», чем «переписать с нуля». Впрочем, иногда нужно действительно начать с чистого листа.
34В проигрыше виновата вся команда Если менеджер уже несколько раз сменил команду разработки, но проблемы остаются, то можно уверенно утверждать, что дело не в разработчиках. Такое же правило действует и в отношениях Заказчик-Подрядчик. Это командная работа, и в проблемах на проекте не может быть виновата только одна сторона.
35Не планируйте, развивайтесь здесь и сейчас Иногда менеджеры и команда стараются предугадать развитие проекта на год или два. В большинстве случаев это пустая трата времени и сил. Внешняя среда неоднородна и не всегда предсказуема, реальный опыт использования может существенно изменить взгляды на полученный результат — поэтому, залог эффективного и долгосрочного развития проекта не в тщательном планировании на годы вперед, а в создании такой среды разработки, в которой можно органично менять и переделывать сделанное ранее.
36Предусмотреть все — невозможно «Сразу умножайте на число Пи». С одной стороны, программирование происходит в условиях недостаточного проектирования, когда постоянно вскрываются какие-то уточнения и детали, которые ранее не прорабатывались. С другой стороны, разработчик обычно очень оптимистичен, т.к. ему кажется, что он все предусмотрел. К сожалению, бороться с этим практически невозможно и приходится просто учитывать это в своих оценках.
37Хороший менеджер всегда суров По ходу проекта Заказчик всегда не очень доволен хорошим менеджером, потому что тот спорит, гнет свою линию, заставляет Заказчика принимать решения и делать выбор. Плохой же менеджер очень мил, приветлив и всегда со всем согласен.
38Убирайте все лишние звенья Обычно, по ходу продвижения задачи вглубь команды, начинает размываться ответственность. Если бизнес-потребитель (Заказчик) сильно переживает из-за какой-то задачи, то менеджер уже переживает чуть меньше, в то время как конечный исполнитель может вообще не чувствовать никакой ответственности за результат. Чем больше звеньев в этой цепи, тем сильнее наблюдается такой эффект, поэтому, если у вас есть возможность сократить какое-то звено или спрямить коммуникации, этим обязательно стоит воспользоваться.
39Лучше один раз увидеть… Если что-то в рамках проектирования можно описать картинкой, а не текстом — это всегда предпочтительнее. Чем легче Заказчику, как источнику знания, оценить предлагаемый проект, тем быстрее мы получим знания о реальных требованиях и ожиданиях и уменьшим риски.
40Фокусируйтесь на слабых местах Предельная производительность системы определяется по наиболее узкому ее звену. Если вы не успеваете с версткой, то бесполезно торопить программистов. Если менеджер уделяет слишком мало времени, то команда будет заведомо неэффективна. Фокусируйтесь на этих «узких местах», последовательно их устраняя.
Полный текст статьи читайте на CMS Magazine
