Здравствуй, Хабрачеловек!
Я работаю программистом вот уже 5 лет. Из них 2 года работаю удаленно.
Идея написать статью, обращенную к менеджерам управления проектами, родилась, когда возникло подозрение, что некоторые менеджеры при работе с программистами не понимают некоторых аспектов или упускают их из вида.
Во-первых, еще раз уточню, что это взгляд программиста, а не менеджера.
Во-вторых, картина сложилась исходя из работы с 4-мя менеджерами. С 2-мя последними работа велась удаленно.
Итак, актуальный вопрос: почему программисты срывают сроки, работают неэффективно? И что можно с этим сделать?
Я не знаю, как объясняет себе такую ситуацию менеджер. Можно предположить, что он считает виноватым себя: сроки были изначально оценены неправильно, задача была поставлена не тому программисту. Может быть, он считает виноватым программиста: программист недостаточно квалифицирован, недостаточно мотивирован или просто ленив.
Мне не встречались ленивые программисты. Может быть, повезло.
И все же тезис таков — в большинстве случаев вина не в том, что программист ленив или недостаточно квалифицирован. Проблему можно лаконично оформить списком от самой распространенной причины до менее распространенной:
Сроки срываются, когда:
- Программист не понимает, чего от него хотят
- Программиста часто отвлекают
- Программист устал
Это бывает достаточно часто. Когда? Да например:
Случай 1. Руководство точно не решило, чего оно хочет, и поэтому задачи сформулированы нечетко.
Первый совет.
Формулируйте задачу как можно конкретней.
Чем конкретнее сформулирована задача, тем меньше времени на нее уйдет. Это должно быть написано золотыми буквами в библии менеджера.
Второй совет.
Почаще спрашивайте, всё ли понятно. Дружелюбно, без намека, что там и так все понятно.
Может быть, вы обсуждали эту задачу с руководством несколько дней. Почему программист должен понять сразу, что вам нужно?
Случай 2. Менеджер потерял контроль над тем, что происходит в системе и ставит задачу добавить то-то туда-то, когда этого места в системе нет.
Программист сначала пытается выяснить, может, он сам чего-то не понимает, прежде, чем спросить. А это — зря потраченное время. Менеджеру важно помнить, что программист не видит всего процесса разработки, он видит только свою часть или, может быть, большую часть, но не всю. Программист в большинстве случаев не знает конкретно, что делают его коллеги.
Когда менеджер ошибается, это выливается в зря потраченное время.
Третий совет.
Вы — менеджер, так что не ошибайтесь.
Случай 3. Программист не понимает, на какой стадии процесса находится разработка. Не понимает, насколько тщательно он должен прорабатывать детали. Одну и ту же задачу можно выполнить с разной степенью тщательности и, соответственно, уделить ей разное количество времени, но об этом почему-то не упоминается в задачах.
Четвертый совет.
Держите программиста в курсе дел. Уточняйте, насколько тщательно должна быть выполнена задача.
Если вы знаете, что рукводство еще точно не решило, надо ли это реализовывать и вполне возможно, что вскоре надо будет переделать все с точностью до наоборот, не скрывайте правды от программиста.
Если вы планируете вскоре нанять тестеров, почему бы ни сказать об этом? Почему-то тестер частенько появляется «Вдруг».
Если предстоит проверка проекта другими учреждениями или важный показ, подчеркните важность этого события. В этом случае недостаточно сказать один раз, что у нас планируется проверка от «тут непонятное название». Нужно, чтобы программист осознал, что это серьезно.
Случай 4. Программиста часто о чем-то спрашивают и не дают сосредоточиться.
Пятый совет.
Если у вас есть новичок, берите в расчет время, которое на него потратят опытные программисты.
Вопросы отвлекают. Если менеджер на все вопросы нового программиста посылает его за ответами к более опытным, это сильно скажется на сроках. Фраза «Помоги тому-то с тем-то» — очень опасная. Надо хорошо понимать, когда ей пользоваться. Эта фраза может помочь, но может и остановить процесс разработки у обоих.
Случай 5. Программиста просят передать задачу другому программисту.
Шестой совет.
Не говорите программисту, чтобы он сказал что-то сделать другому программисту.
Не сваливайте свою работу на других или вам придется писать код самому :)
Случай 6. Враг эффективности — усталость.
Седьмой совет.
Если у программиста упала производительность, и он работает без отпуска больше полугода, то предложите ему отпуск.
Хотя бы на 2 дня. Это окупится сторицей.
Не стоит забывать, что отдохнувший программист — это хороший программист!
P.S. Надеюсь, что это письмо дойдет по нужному адресу.
С Наступающим!