История о двух программистах 2

Это не продолжение истории о двух программистах, а другая история.


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

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

Процесс достаточно подробный и детализированный. Засады чаще всего встречаются по причине того, что никто почти не знает функционал в объёме, достаточном для осознания значимой части задачи.

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

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

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

Это несколько удивляет, даже если не знать ещё более шокирующих подробностей, которые скрыты. Первый программист (тот, который «негатив») работает почти все 8 часов в день на этом проекте и отчитывается за эти 8 часов. А вот второй («позитив») затрачивает 2-4 часа (в среднем 3) своего ежедневного времени на этот проект и при этом отчитывается за те же 8.

Программисты приблизительно одного технического уровня. За счет чего у второго такой выигрыш?

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

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

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

1-ый пункт, а точнее подход, позволил нащупать 2-ой и 3-ий, которые дают в совокупности возможность управлять программисту структурированным чужим процессом снизу в комфортных оценках и застрахованных задачах. Получился выгодный покупатель.

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