Перейдём к более общим практикам. Какую привычку или практику ты бы вообще выпилил из отрасли? То, что, по твоему опыту не приносит, а мешает.
Сложный вопрос — у нас просто сейчас очень адекватный заказчик и довольно здоровые процессы. Но если говорить в целом по индустрии, я бы выделил такую практику: полная изоляция IT-команды от заказчика.
Когда вся коммуникация идёт только через PM’а или продуктолога. Есть один–два человека-«шлюза», и через них проходит всё общение. Разработчики никогда не общаются напрямую с бизнесом, не ходят на общие созвоны.
Эта практика, с одной стороны, «экранирует» разработчиков от давления, от эмоциональных качелей заказчика, улучшает атмосферу в команде. В этом действительно есть плюсы. Но с другой стороны, сильно снижается скорость и качество обратной связи. Не всегда понятно, как люди реально пользуются фичами, что им неудобно, какие у них ожидания на будущее.
В такой ситуации есть риск релиза фич, которыми потом невозможно пользоваться в реальной жизни. Не потому, что разработчики плохие, а потому что где-то по пути потерялся контекст, что-то не спросили, не учли, неправильно поняли. Плюс риск неправильной приоритизации, потому что о планах как следует никто не поговорил.
Иногда проблема не в том, что разработчики не общаются с заказчиком, а в том, что тот самый «шлюз» — аналитик или PM — что-то недоработал. Ты с этим согласен?
Отчасти да, но я бы всё равно смотрел на это как на вопрос процесса, а не конкретного человека. Если у тебя один аналитик ведёт одну задачу от начала до конца, то да — он может что-то не учесть, где-то ошибиться, о чём-то не спросить. Все люди ошибаются. И чем дольше всё держится на одном человеке, тем выше риск.
Если бы на каком-то этапе — не обязательно с самого начала, хотя бы ближе к концу — подключались другие люди и обсуждали всё вместе, в том числе с заказчиком, качество ТЗ и решений было бы выше.
Здесь похожая история. Разработчики не могут почувствовать, как система живёт в руках пользователей, если они вообще не видят этих людей и не слышат их голос.
Если, например, хотя бы на этапе демо перед выкладкой на прод подключать тех, для кого делалась фича, можно заранее поймать несовпадения ожиданий и реальности. Прокликать сценарий, посмотреть, где неудобно, и заложить время на доработки ещё до релиза.
Раз уж мы ушли в тему коммуникации, должен ли разработчик уметь объяснять свои решения простыми словами и понимать «обывательский» язык запросов бизнеса?
Не везде есть идеально настроенные процессы передачи информации от бизнеса к аналитике, от аналитика к разработке и дальше. Часто приходится самим «переводить» туда-обратно. Мне кажется, это как раз тот навык, тот софт-скилл, который универсален не только для разработки, но и вообще для любой отрасли.
В нашей команде этот скилл мы развиваем на перфоманс-ревью. Берем примеры, когда что-то вовремя не спросили, когда что-то было не так описано. Важно все эти проблемы не замалчивать и не обсуждать абстрактно. Лучше всего учат конкретные примеры.
На сеньорном грейде навык перевода с разработчиковского на русский должен быть вообще у каждого, на мой взгляд. Потому что делать это не только с заказчиком надо будет, но и с командой. Нужно будет на техдемо, например, объяснять фичи всей команде. Ну а в идеале, конечно, уметь это делать уже будучи мидлом.
