[В серии Объясни мне это, как будто я менеджер]
Представим, что вам платят за написание электронных писем.
Компания, в которой вы работаете, придерживается политики, согласно которой все публичные электронные письма от руководителя должны быть написаны кем-то с ясной головой и надлежащим обучением. Это ты.
Работает это так:
- Вы получите личный брифинг от руководителя о том, о чем идет речь.
- Вы возвращаетесь в офис, чтобы поработать над электронной почтой. В случае возникновения вопросов вы звоните руководителю и обычно сразу получаете ответ.
- По завершении вы представляете свое электронное письмо и вместе редактируете его, пока оба не останетесь довольны результатом.
Весь процесс занимает от получаса до нескольких часов.
Вроде нормально. Это может быть даже весело, правда?
А теперь представьте себе другой способ работы
Единственная разница в том, что вы не уверены, когда получите отзыв или одобрение. Это может произойти сразу, а может потребоваться несколько недель.
Поскольку вы не знаете, сколько времени это займет, вы начинаете работу над следующей задачей. Вместо того, чтобы иметь одно электронное письмо «в процессе», у вас может быть 20, 30 или намного больше.
Это та же самая работа, с теми же входными данными, но она кажется намного более громоздкой и намного менее увлекательной, или нет?
К сожалению, так работает большинство разработчиков.
В этом примере мы предполагаем, что нет посредника (PM, аналитик…), через который проходит все общение, внедряющее свои собственные идеи, запутывая сообщение в процессе.
Как разработчик, я часто очень расстраивался, когда на получение отзывов или ответов уходит много времени.
Вы начинаете над чем-то работать. Вы застряли, вам нужна обратная связь. Поскольку вы не знаете, когда получите ответы, вы откладываете задачу и начинаете работать над следующей.
Но подождите, у клиента такое же разочарование!
Да, я был там: в течение нескольких лет я работал с другой стороны, руководя подрядчиками / фрилансерами по разработке специального программного обеспечения для нашей организации.
Так же досадно давать подробный отзыв разработчику только для того, чтобы через две недели получить дополнительные вопросы. Обычно на эти вопросы можно было бы легко ответить, если бы задать их сразу, но через две недели я с трудом могу вспомнить, о чем все это было!
Конечно, есть способы лучше потратить время зря!
Какое инженерное решение?
Давайте воспользуемся инструментом для управления всей этой «незавершенной работой» со статусами, флагами, сроками выполнения, интеграцией источников, настраиваемыми полями, назначенными лицами, отчетами, контрольными точками и всем остальным.
Это часто ненужное чрезмерное усложнение, которое считается стандартной практикой.
"Вот как это сделано!"
Действительно, существуют ситуации, которые требуют такого подхода к работе.
Но большинство программных проектов на самом деле довольно просты и не получают выгоды от этих «решений».
Основная причина все еще существует: получение обратной связи занимает слишком много времени. Как люди, мы не можем временно хранить свое накопленное понимание - нашу «хватку» - где-то до тех пор, пока оно нам снова не понадобится.
Итак, какая альтернатива?
Мы все заняты и не можем просто бросить то, над чем мы работаем, когда кто-то требует нашего внимания. Но что, если бы мы могли?
Что, если бы мы могли работать над 2–3 задачами одновременно?
Что, если бы нам не потребовались инструменты (кроме базового списка дел) для управления ходом выполнения всех наших задач?
Что, если бы мы могли интенсивно работать с клиентом над несколькими задачами от начала до конца? И не начинать новую задачу, пока она не будет полностью завершена?
Почему я задаю эти вопросы? Потому что это сэкономит время, деньги и нервы!
Это один из основных элементов нескольких структур управления задачами / проектами, которые предлагают сосредоточиться на ограниченном количестве задач во время так называемых «спринтов» или которые налагают ограничение на «незавершенную работу» (предел незавершенной работы).
Часто выступают. Практикуется редко.
И действительно, никто не просит вас бросать все при каждом вопросе; просто не позволяй вещам скользить вечно.
Неужели мы тратим столько времени на ожидание обратной связи?
Было исследование, проведенное компанией Palm в Калифорнии, производящей первые КПК. В этом исследовании измерялось, сколько времени требуется разработчику, чтобы исправить ошибку, обнаруженную через 3 недели, а не в тот же день.
Как вы думаете, сколько времени это займет?
Примерно в двадцать четыре раза больше, независимо от того, большая или маленькая задача.
Вы тоже упали со стула? Мое первоначальное предположение было 5–10 раз, что должно быть достаточно, чтобы вдохновить кого-нибудь дополнительно подумать об этом.
Но бесконечное ожидание обратной связи - не единственная причина стремительного роста незавершенного производства!
Это также:
- Задержка между анализом и разработкой
- Задержка между разработкой и тестированием (при использовании тестеров)
- Задержка между тем, как разработчик прочитает отзыв тестировщика и отреагирует на него.
- Ожидание одобрения или одобрения чего-либо
- …
Теперь, как нам это исправить?
Что ж, не так уж и сложно… написать об этом! 🙂
Вот мои предложения, которые должны работать независимо от вашей роли:
- Попытайтесь привлечь всех на борт. Отправьте им ссылку на эту статью. Или отправьте им этот отрывок из Scrum Book; автор просто немного более известен, чем я, так что это может сработать лучше! 😉
- Подавать пример: оставлять отзывы и отвечать на вопросы в тот же день или, по крайней мере, в течение 24 часов.
- Четко заявите, что вы пытаетесь дать отзыв как можно скорее. Активно требуйте того же от всех, с кем работаете, включая клиентов и менеджеров. При необходимости проконсультируйтесь. Многие люди не обращают внимания на вещи, пока не заметят, что вы постоянно следите за ними.
И, если ваша роль позволяет:
- Постарайтесь заставить всех (необходимых / необходимых) работать примерно над одной и той же задачей в одно и то же время.
- Постарайтесь ограничить количество задач и «незавершенную работу». Установите лимит незавершенной работы.
- Сократите количество посредников. Часто они не служат никакой реальной цели, кроме как для объединения или перевода информации. Разработчики часто общаются слишком технически. Я сам до сих пор делаю эту ошибку. Но я также верю, что вы можете научиться общаться на более нетехническом человеческом уровне. Слушайте, что на самом деле говорится, и старайтесь отвечать на том же уровне, используя те же слова.
Я думаю, что всегда лучше иметь прямые линии связи, потому что это улучшает возможность учиться друг у друга.
Но я разработчик. Я не могу просто требовать внимания моего клиента!
Вы не требуете немедленного внимания; вы просите не ждать целую вечность, чтобы получить ответ.
Я знаю, что для многих разработчиков это не стандартный способ работы: быть проактивным, а не реактивным, протянуть руку помощи вместо того, чтобы заниматься очередной пользовательской историей или ошибкой. Я не хочу быть снисходительным. Я говорю из своей собственной практики, из ошибок, которые я сделал, из опыта неудачных и успешных проектов.
Это может быть один (из многих) шагов к тому, чтобы стать 10-кратным инженером и показать, что вы в курсе дел и заботитесь о проекте.
Помните, что все эти люди, не являющиеся техническими специалистами, с которыми вы работаете, действительно мало разбираются в разработке программного обеспечения.
Нет ничего плохого в том, чтобы управлять и обучать их тому, как оптимизировать процесс и сэкономить время и деньги. Кто мог быть против? (Если, конечно, ваше время не оплачивается по часам 😉
… А что, если вы получаете обратную связь из нескольких источников, противоречащих друг другу, даже противоречащих вашему собственному мнению?
Другое дело - Дизайн комитетом. Зарегистрируйтесь здесь и будьте в курсе.
Первоначально опубликовано на http://www.hadermann.be.
