Блог

Взгляд программиста

Начнём с терминологии. Главным термином по праву считается «идеальный час программиста». Т.е. идеальный час – это время, потраченное исполнителем исключительно на задачу.


Есть два кардинально отличающихся друг от друга подхода к процессу постановки и оценки задач:


1. Строится на понятии «идеальный час» и спускается «сверху» - менеджер, руководствуясь предложенными ему идеальными оценками, отводит время на задачу и ставит её программисту.


2. Второй подход также основан на понятии «идеальный час», но он уже соотносится не с менеджером, а с программистом, который будет делать задачу. Оценка в соответствии со своими навыками и возможностями.


В первом случае оценка строится на усреднённой оценке. Это приемлемо для больших и маленьких компаний с однородными (по квалификации) сотрудниками. Во втором случае мы имеем оценку более реальную, но уже с точки зрения программиста. Однако и её недостаточно. Программист может быть опытным в написании кода, но, не имея опыта в оценке задач, он не сможет корректно оценить обширную или узкоспециализированную задачу. 


Копнём вглубь и рассмотрим вполне себе типичную ситуацию в маленькой региональной веб-студии. Программисты дают какую-либо оценку, потом менеджеры ее усредняют и ставят в задачу. ОK, со стороны это выглядит адекватно. Но есть несколько «НО»:


1.    Неопытный программист даёт заниженную оценку


2.    Неопытный программист даёт завышенную оценку


3.    Недобросовестный программист даёт завышенную оценку


4.    Добросовестный программист дает завышенную оценку


5.    Программист дает идеализированную оценку


Разберём каждый случай чуть подробнее. В первом случае мы получаем задержку проекта. Второй случай ведёт к дополнительным вопросам со стороны заказчика по финансовой части. Третий – пожалуй, самый пагубный вариант как для программиста, так и для студии. Попросту потому, что на завышенные оценки этого программиста могут ориентироваться остальные сотрудники. Четвёртый случай – программисты постоянно учатся и набираются опыта. Кто-то быстрее, кто-то медленнее. И в один прекрасный момент в компанию может прийти программист, который на прежней работе мог ставить задачи себе сам, или менеджер был таков, что необходимо было ставить задачи самому. Поэтому и происходит завышение оценки. Пятый случай – и такое бывает, но относится к разряду заниженных, поскольку как идеального рабочего дня, так и идеальных условий для проекта нет. 


Кстати, тут можно привести еще один термин: «коэффициент мусорного времени». Грубо говоря, это соотношение непроизводительных часов к производительным. Пожалуй, лучшая характеристика рабочего дня программиста. 


Постановка задач программистам



Например


работа над задачей 3 часа, 
совещание 30 минут,
перекур 15 минут, 
кофе 15 минут, 
работа над задачей 1 час, 
15 минут микро совещание, 
15 минут восстановление деятельности, 
1,5 часа работы
15 минут перекур
15 минут кофе
15 минут микро совещание
15 минут телефонный разговор


Из этого списка видно, что над задачей программист проработал 5, 5 часов из 8  => КМВ = 3,5/5,5. Эта оценка характеризует только данную задачу. Чтобы получить полное рабочее время необходимо сложить все оценки. Кстати, у лучших компаний этот коэффициент примерно 1/7.


Взгляд менеджера


Теперь посмотрим с другой стороны. С позиции менеджера. Менеджеры проектов стремятся подороже продать работу программистов, а заказчики хотят купить её подешевле. Торг заканчивается, и все сходятся на какой-то оценке. Теперь менеджер вправе требовать от программиста выполнения проекта в установленный срок на основе идеального часа. Но, как я уже говорил, идеальных проектов не бывает и «продвинутые» менеджеры вводят свои поправки в на идеальный час. Это тоже приходит с опытом и со многими шишками. Однако и здесь есть свои краеугольные камни.


Если у нас идеальная сферическая команда в вакууме, то эта оценка подойдет и будет единственно верной. Но как мы знаем - таких команд не бывает. В команде программистов (возьмем отдельный отдел) есть разные типы людей с разными способностями и разной квалификацией. Ставя и оценивая задачу, надо учитывать это.


Возьмем такой случай: программист накануне отработал 10-11-12 часов просто из-за аврала. На следующий день его работоспособность сократится примерно вдвое. Если программист не выспался, то он будет невнимательным и медлительным. А это опять же сказывается на выполнении сроков, особенно в период перехода от одного проекта к другому.


Все эти нюансы влияют на сроки выполнения задач, и, как правило, не в лучшую сторону.


Взгляд тимлида


Осталось взглянуть на постановку и оценку задач со стороны тимлида. Этот человек является связующим звеном между менеджерами и программистами. У него в большинстве случаев «коэффициент мусорного времени» больше, чем у других сотрудников отдела. Однако в его руках сосредоточена «власть над временем». Постановка и оценка задач из середины процесса кажется более адекватной, чем две предыдущие.


Это компромисс между постановкой идеального времени и времени индивидуального. 


На мой взгляд, было бы правильно взять опыт Google по жёсткой постановке задач программистам и адаптировать его под требования любой отдельной маленькой, средней или  большой компании.


1.    Постановка задачи происходит сверху.


2.    Задача конкретна, детализирована, разбита на элементы и подзадачи.


3.    Задача ставится сразу на конкретного человека.


4.    Задача оценивается тимлидом или опытным программистом с оглядкой на ответственного по задаче.


5.    Программист обязан выполнить задачу в срок.


6.    Минимизировать мусорное время.


7.    Технической поддержкой занимается один человек, если он не справляется - подключается еще один.


8.    Желательно менять человека на технической поддержке один раз в месяц.


9.    Баги исправляет тот человек, кто их сделал. Если такового нет, то делает человек со смежной задачей. Если и такого нет - делает или самый опытный или тимлид.


Автор: Георгий Ионов, программист отдела веб-разработок

 


Возврат к списку