Три типа душнил в продуктовой команде
В стартапе, да и вообще в любой продуктовой команде, обязательно должно быть три типа душнил:
- Душнила по качеству кода
- Душнила по дизайну
- Душнила по срокам
Качество кода стопудово важно, но красота кода может идти в разрез дизайну. В красиво организованном коде может быть сложно чуток извернуться и сделать идеально красиво внешне. Плюс код можно организовывать до посинения вместо того, чтобы его шипнуть уже наконец.
Поэтому душнилы по дизайну и срокам должны прессовать душнилу по коду.
Удобный UX и красивый визуальный дизайн часто требует времени, экспериментов и нетривиальных технических решений. Между нетривиальными техническими решениями и говнокодом — тонкая грань. Ну и ежу понятно, что совершенство требует времени.
Поэтому душнилы по коду и срокам должны прессовать душнилу по дизайну.
Выполнение сроков требует либо сокращения фукнционала, либо компромиссов, либо и того, и другого. В каких-то случаях это помогает запустить более простой продукт быстро. В других — на выходе получается г.вно с костылями, в интерфейсе которого не могут разобраться даже сами создатели.
Поэтому душнилы по коду и дизайну должны прессовать душнилу по срокам.
Также как в каждом из нас есть мужская и женская часть, в каждом участнике процесса должны жить все три душнилы.
Это очень продуктивно, когда душнила по коду сам думает "блин, это чёто сильно долго" и немного говнокодит, чтобы было быстрее.
Или душнила по дизайну признаёт, что его решение создаст костыли и находит компромисс.
Или душнила по срокам осознаёт, что чрезмерная оптимизация даст на выходе полное г.вно, которым никто не будет пользоваться.
В нашей команде собрались все трое. Арнаб — кодовый душнила, я — дизайновый, а Дженни — душнила-срочница. Мы хорошо дополняем друг друга, хоть и не без конфликтов.
Споры благополучно решаются благодаря тому, что мы все хорошо понимаем все три стороны и мы рациональны. Хотя иногда мы можем помусолить какое-нибудь относительное простое решение неделю из-за того, что не можем договориться о том, как оно должно выглядеть или какие слова там должны быть написаны.
В итоге мы негласно пришли к модели, которую практикуют основатели Basecamp. Если мы не можем договориться, то последнее слово по дизайну как правило за мной, а последнее слово по коду — за Арнабом.
По срокам у нас обычно получается договориться без "права вето," хотя, должен признаться, сроки — это слабая сторона нашей команды. Иногда сильно увлекаемся качеством.