Принципы Эмерсона

Не так давно на хабре промелькнула заметка, в которой 12 принципов эффективности Эмерсона были адаптированы для улучшения личной производительности фрилансера. В какой-то степени принципы, сформулированные Эмерсоном, универсальны, и применять их можно во многих сферах деятельности. Ниже приведены мои соображения по каждому из 12-ти пунктов в рамках разработки программного продукта. Сразу стоит оговориться, что многие вещи тесно связаны с методологией разработки, используемой в команде.


1. Четко поставленные цели производства и четко обозначенные задачи персонала. Цель разработки - это не создание сферического коня в вакууме, а выпуск продукта, который решает определенные задачи. Тут можно развести отличную демагогию по поводу основных задач, ради которых и затевался проект, и дополнительных, которые являются приятными бонусами, плюшками, но которым, зачастую, уделяется слишком много внимания. Поэтому кратко: декомпозиция + расстановка приоритетов.

2. Здравый смысл должен быть везде и во всем:
В выборе проекта:
Отклонять на предложения типа “Если вы готовы сделать проект Х за это за У месяцев за Q денег, то по рукам!”, зная, что сроки сильно преуменьшены. Такой проект обречён: сорванные дедлайны, замученная бессонными ночами команда и, как следствие, некачественный продукт.
В выпуске продукта:
Всему есть предел. Если не выпустить продукт сейчас - значит, не выпустить его никогда. Всегда нужно помнить: лучшее враг хорошего, и достаточно хороший продукт в эксплуатации уже работает на вас, а почти идеальный в бесконечной стадии завершения - всё ещё только код в IDE.
В убиении:
Толика храбрости придётся кстати: реалистично оценивая ситуацию, закрывать безнадёжные проекты ещё до того момента, как они начали исчисляться убытками в крупных размерах.

3. Компетентная консультация. Вряд ли кто-то доверит фельдшеру делать операцию на сердце. А ведь он тоже врач. В каждой профессии есть свои узкие направления, специализации. За знания нужно платить. Не экономьте на кардиохирурге.

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

5. Справедливое отношение к персоналу, выражающееся в идее «лучше работаешь — лучше живешь». Просто лозунг для стахановского движения какой-то. Сложный пункт для адаптации относительно к разработке. Что понимается под “лучше работаешь”? Выдаешь больше кода? Так сейчас наговнокодим! Или код более качественный? Бесконечный рефакторинг, о да! Что подразумевает “лучше живёшь”? Карьерный рост (и увеличение ответственности, к чему далеко не все программисты стремятся)? Увеличение зарплаты? Бонус в конце года? Где-то была история (не помню, где), что разработчик, чей коммит поломал всё, оставался делать ночной билд. И справедливость, и мощная мотивация для “семь раз отмерь, один раз отрежь”.

6. Обратная связь. Без обратной связи проект обречён. Если разработчики только получают задания, но не могут высказывать своего мнения - фейл. Если пользователи только могут покрутить-повертеть очередную версию продукта, но их отзывы и мнения не доходят до разрабочиков - фейл. Обратная связь должна быть всегда, везде, на всех уровнях.

7. Порядок и планирование работы, диспетчирование. Специфично для выбранной методологии процесса разработки (xp, scrum, kanban & etc.) См. п. 8.

8. Нормы и расписания. Что такое норма кода? Сколько строк в час? Не понятно. Может, по заданию на рабочий день? Но задания тоже разные бывают. Не нравятся мне эти нормы, поэтому нормы вычеркиваем, расписания оставляем таком виде:

9. Нормализация условий. Тут есть, где разгуляться: начиная от физических условий труда (удобный стол, хороший монитор, комфортное кресло, любимый блокнот IDE, быстрые тестовые сервера, git / svn / mercurial и тд) и заканчивая атмосферой в коллективе. Отношения между людьми - отдельная серьезная тема. Сплоченная, дружная команда - одно из необходимых условий для успеха..  

10. Нормирование операций. Сроки - тема насущная. Заказчик хочет быстрее, разработчик с мешками под глазами доказывает менеджеру, что быстее - никак. Нормирование - это распределение заданий по спринтам. По окончанию каждого спринта четко виден прогресс разработки, что очень удобно: заказчику есть, что пощупать, он может высказать свои "фе" еще на той стадии, когда исправления обходятся не дорого. 

11. Письменные стандартные инструкции. Это документация. Грамотно составленные спецификации, хорошая документация wiki - и в разы меньше окаывается порог вхождения нового человека в проект, а также сопровождение проекта в дальнейшем. bug-tracker, ticket-система - вё это из разряда must have.

12. Вознаграждение за производительность. Ещё одна довольно сложная и объемная тема. Как измерить производительность? Кого поощрять? Чем лучше поощрить? В любом случае, никогда не стоит забывать об отдыхе - порой это лучшая награда :)