После митапа «Постановка задач глазами руководителя и исполнителя: как обеспечить предсказуемый результат»

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

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

Если кратко выразить основную мысль первого выступления — задачу исполнителю надо ставить так, чтобы человек не затруднялся головой, а просто брал и делал, чтобы он понимал какого результата от него ожидают, чтобы он знал как оценить качество выполнения своей работы над задачей.

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

Затем она перешла к рассказу о том, как можно улучшить качество постановки задач.

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

Чеклист эффективной постановки задач по мнению Екатерины:

Рассказывая про эффективную постановку задач, спикер говорила, что наилучший способ ставить задачи — максимально подробно расписать её. Что другие способы менее эффективны.

Руководя компанией по разработке web-приложений уже больше 10 лет, у меня сформировались свои собственные правила постановки задач, которые опираются на тип исполнителей. Это особенно важно, когда речь идёт про такую тонкую материю, как разработка программного обеспечения.

Говоря очень грубо, программистов можно разделить на 2 большие группы. Несмотря на то, что они делают похожие вещи, между ними существует принципиальная разница:

По моим ощущениям творцов примерно 10% от общего числа разработчиков. Остальные — программисты.

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

Одной из основных задач Творца (тимлида, архитектора) — взять проект, подвергнуть его анализу, произвести декомпозицию задач таким образом, чтобы программисты, которые их получат, не выпадали из потока.

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

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

Тут всё сложнее и тоньше. Надо чувствовать, что ли. Творец — уникальный тип личности, требующий очень бережного отношения. Застопорить творческую составляющего такого человека проще простого.

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

И, конечно, простой творца в разы дороже простоя разработчика.

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