Алгоритм вместо решения

Если ты технарь и профессионал, то в управлении всегда возникает неизбежное желание «взять и сделать всё самому». Естественно, это проще и понятнее — тебе самому, конечно. Но так делать не надо. Рук всего две, часов всего 24.

Тесно сопряжено с декомпозицией, и назначением задач.
Подарю лайфхак. Даже два.

И в нашем блокнотике без баек и отсылок не обойдется.

В западной культуре персонаж Ангуса «Мака» МакГайвера встречается примерно повсеместно, тогда как нас в Азии и Восточной Европе обошел стороной. Хорошо, если отсылку по имени вспомнят.

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

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

Итак, вернемся к нашей проблеме. Для постановки задачи другому человеку, из мяса и мыслей, необходимо как минимум описать суть проблемы, и необходимые изменения для ее решения. Те самые «суть» и «надо». С ними понятно.

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

А если нет? Вопроса бы не возникало, если бы в голове автора задачи-технаря уже не было «идеального решения задачи», которое знает только он сам. Это же кошмар интроверта: надо кому-то всё доверить, полагаться на понимание задачи, и на качество реализации. Делегирование — это сложно.

Проблему выбора пути решения можно решить «в лоб»: просто написав целиком, как это сделать. Но этот подход тоже не слишком эффективен, на практике. Есть особенности.

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

Во-вторых, описать максимально полное решение собственно и означает «решить задачу самому». Еще и потратив время на описание. Понятное дело, что так делать не надо, практический технарский смысл сводится к нулю и к лишней работе. Так делегирование не работает.

В-третьих, ваше описанное решение может быть, а может не быть идеальным. Даже если оно кажется таковым в моменте, даже простой лаг в 2-3 дня уже может означать, что ситуация поменялась, есть какие-то новые вводные, которые надо учесть, или обновленные рабочие данные (из фактической среды), с которыми теперь надо подружиться и достичь результата.

Не пишите инструкцию. Пишите алгоритм решения.

Лайфхак-1. Если вы представляете себе путь решения, и он кажется вам подходящим. Добавьте блок описания задаче «как бы я это решал», дословно.

Что следует упомянуть:

• есть ли уже под рукой средства, предназначенные для решения задачи?
• решалась ли похожая задача уже в продукте/проекте, в предметной области?
• есть ли отраслевые практики с удачными решениями? решения конкурентов? описание в гугле?
• какой путь решения вы бы сами выбрали, и почему именно его
• если есть (или обнаружится) несколько подходящих вариантов, чем следует руководствоваться при выборе?
• опишите явно, что делать, если появится необходимость расширения задачи (идти с вопросами, детализировать самому, обращаться к аналитикам итп)

Что это даёт:

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

Лайфхак-2. Если вы с точки зрения своего опыта и понимания знаете, что в некоторых местах выбор решения может быть не столь тривиальным. Добавьте блок описания «важные условия».

Что следует упомянуть:

• очевидно, если при решении есть важные моменты или ограничения. Если вы о них знаете/помните, совершенно не факт, что в нужный момент о них вспомнит исполнитель. Надо написать.
• что является критерием выполненной задачи; что оно должно делать, а чего наоборот, не должно. Тесно связано с Definition of Done из agile-методик
• если есть проверочный сценарий для результата — надо его написать (или сослаться)
• если решение обязано использовать какие-то из подходов или технологий, напишите сразу. Не все обязаны разбираться сразу во всём зоопарке вариантов
• если есть метрики, в которые надо попасть, или оценочные цифры (надежность, устойчивость, скорость, объем итп), worth notable
• и также как и в предыдущем блоке, алгоритм выбора нужного решения из нескольких

Что это даёт: осознанные проработанные риски, и критерии в планировании решения.

Итого: вместо изобретения очередной тупой пошаговой инструкции, вы 
а) описали один из подходящих путей решения, рамочно (но не потратив кучу времени на детализацию), и 
б) подсветили те узкие места, о которых уже знаете сейчас.

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

Вот нож и изоленту, считайте, я вам уже дал.