Не существует идеального размера цикла обратной связи
Чем больше я писал этот пост, тем больше мне казалось, что я должен написать что-то вроде TL;DR для определенных людей, которые это читают. Итак, в целях экономии времени, вот:
Я пишу это для тех, кто плохо знаком с самозанятостью, управлением проектами или вообще имеет меньший опыт, чем те, кто спрашивает: «Зачем вы это пишите?» В конечном счете, это то, чему большинство из нас учат в какой-то момент этого промышленности, но если мы сможем помочь друг другу сократить путь раньше, чем позже, мы все выиграем.
Если вы все еще заинтересованы после прочтения примечания выше, то я предполагаю, что вы хотите стать лучше в этом аспекте общения. Это хорошо, потому что я тоже 😏, и использование небольшой петли обратной связи — один из способов, который я нашел для этого.
В каждой отрасли есть свой жаргон, и многие из нас смеются над ним, но все мы продолжаем использовать его в профессиональной среде. Мы такие забавные.
В любом случае, в нашей отрасли одна из фраз, которую мы часто используем, включая меня, — это «петля обратной связи». Впервые я столкнулся с этой фразой в связи с обратной связью от усилителей. Это не имело никакого отношения к программному обеспечению. Тем не менее, в том, что мы делаем, мы обычно используем его для обозначения:
- отправка запроса, комментария или общей информации клиенту,
- получение ответа от заказчика по указанной информации.
А для тех, кто не привык к этой идее (потому что есть те, кто выпускает «большие релизы», о которых я расскажу через минуту), циклы обратной связи обычно считаются маленькими или большими.
Чем дольше я работаю в программном обеспечении, тем больше я всегда стремлюсь к Небольшому циклу обратной связи, несмотря ни на что.
Идеальный цикл обратной связи
Небольшая петля обратной связи означает, что существует частое общение между бизнесом и клиентом (поэтому, естественно, большая петля обратной связи — это когда общение происходит реже).
Если вы собираетесь использовать жаргон, по крайней мере, подумайте об этом как-то весело, верно?
Но вы знаете весь этот жаргон, который я упомянул в начале статьи? При обычном преобразовании я бы просто сказал:
Когда дело доходит до работы над проектом, я предпочитаю более частое общение.
И причина, по которой я предпочитаю это и даже использую по умолчанию, заключается в том, что когда дело доходит до создания решения, независимо от размера, для кого-то еще, всегда есть движущиеся части, которые необходимо учитывать.
Когда проект состоит из нескольких частей, существует множество мест, где что-то может нуждаться в настройке или изменении (или это может повлиять на всю систему), и правильное выполнение этого раньше, чем позже, сэкономит много времени (и, следовательно, денег) и стресс для большинства вовлеченных сторон.
И что?
Хотя зачем писать об этом? Для меня причина в том, что чем дольше я управляю небольшим магазином, тем больше я слышу от клиентов о проблемах, связанных с отсутствием ясности, коммуникации и управления проектами в предыдущих проектах.
облом. Я не хочу проводить такие операции. Так это легко исправить, верно?
Кроме того, в индустрии разработки полно людей, которые принимают требования проекта, предполагают, что они понимают все, что нужно, а затем возвращаются только для того, чтобы создать что-то, что не только не соответствует цели, но и лишь немного похоже на то, что задумал заказчик.
Это не обязательно удар по программистам, но все это «[отсутствие] цели» можно исправить, если бы мы просто общались с теми, с кем мы работаем, немного чаще, чем нет.
Не думайте, что вы знаете, чего они хотят.
Вместо этого задавайте вопросы, уточните требование, поработайте над функцией, а затем представьте ее клиенту в тестовой среде. Они узнают, построили ли вы то, что они просили. Если да, то переходим к следующей функции. Если нет, есть еще над чем поработать. Работая таким образом, можно упростить множество точек напряженности, возникающих в проектах.
И да, задавать много вопросов может стать утомительным и даже раздражающим. Большое дело. Упомяните с самого начала, что вы собираетесь задать много вопросов, чтобы полностью понять проблему, прежде чем пытаться ее решить. Назовите причину, почему вы делаете то, что делаете. Обычно это хорошо окупается.
Релизы Большого Взрыва
Ранее в посте я упоминал «выпуски большого взрыва», и это обычно относится к идее клиента, предоставляющего вам требования, вы возвращаетесь к работе над ним в течение нескольких недель, а затем возвращаетесь и говорите: «Эй, я Готово — смотри!» только чтобы узнать, что это далеко.
Если бы мне нужно было контекстуализировать это в рамках типа цикла обратной связи, я бы сказал, что его нет. Это даже не большой, потому что не было запрошено никакой обратной связи. Это просто:
- Вот требования к проекту,
- Я закончил с проектом.
Часто это приводит к тому, что разработчики неправильно понимают требования, клиенты остаются в неведении относительно прогресса, а проект в целом идет на спад. Проще говоря, не делайте этого таким образом.
Идеальный размер?
Я не знаю, каков идеальный размер петли обратной связи. У некоторых клиентов, с которыми я работал, есть ежедневные проверки, есть и еженедельные проверки, а есть такие, которые сказали: «Просто заполните это и дайте мне знать, когда закончите».
Еженедельные проверки, коммиты, релизы и т. д., как правило, мои любимые, но это из-за размера проекта и размера команды, с которой я работаю. Ежедневно тоже неплохо, в зависимости от задачи.
Я никогда не работаю в стиле большого взрыва, даже если клиент говорит, что это нормально. Мне все еще нравится иметь контрольные точки для собственного здравомыслия. Таким образом, любой тип цикла обратной связи лучше всего подходит для вас, вашей команды и вашего клиента.