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

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

Люди с энтузиазмом воплощают свои собственные идеи, но чужие планы они выполняют с неохотой. Тем более, если эти планы директивно спустили сверху. Чтобы сотрудники приняли и реализовали вашу идею так, будто они сами ее придумали — используйте эти 6 шагов.

На примере одного случая из практики я хочу показать, почему руководителю важно в кризисный момент найти в себе силы и честно сказать команде: «Ребята, я не вывожу».

На входе наш продукт выглядит как кнопка с плюсиком, но за ней спрятана сложная логика и 1,5 года работы до запуска MLP.

Мы привыкли жаловаться на бесконечные встречи и чаты, на то что не хватает времени на главное, всё занято текучкой. И даже воспринимаем это как данность, как необходимое зло, издержки профессии. Так ли это? Посмотрим, сколько рефально стоит коммуникация. Команде в целом, и руководителям лично. С помощью каких инструментов сократить эти расходы и какой выигрыш можно получить.