Три типа душнил в продуктовой команде

В стартапе, да и вообще в любой продуктовой команде, обязательно должно быть три типа душнил:

  1. Душнила по качеству кода
  2. Душнила по дизайну
  3. Душнила по срокам

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

Поэтому душнилы по дизайну и срокам должны прессовать душнилу по коду.

Удобный UX и красивый визуальный дизайн часто требует времени, экспериментов и нетривиальных технических решений. Между нетривиальными техническими решениями и говнокодом — тонкая грань. Ну и ежу понятно, что совершенство требует времени.

Поэтому душнилы по коду и срокам должны прессовать душнилу по дизайну.

Выполнение сроков требует либо сокращения фукнционала, либо компромиссов, либо и того, и другого. В каких-то случаях это помогает запустить более простой продукт быстро. В других — на выходе получается г.вно с костылями, в интерфейсе которого не могут разобраться даже сами создатели.

Поэтому душнилы по коду и дизайну должны прессовать душнилу по срокам.

Также как в каждом из нас есть мужская и женская часть, в каждом участнике процесса должны жить все три душнилы.

Это очень продуктивно, когда душнила по коду сам думает "блин, это чёто сильно долго" и немного говнокодит, чтобы было быстрее.

Или душнила по дизайну признаёт, что его решение создаст костыли и находит компромисс.

Или душнила по срокам осознаёт, что чрезмерная оптимизация даст на выходе полное г.вно, которым никто не будет пользоваться.

В нашей команде собрались все трое. Арнаб — кодовый душнила, я — дизайновый, а Дженни — душнила-срочница. Мы хорошо дополняем друг друга, хоть и не без конфликтов.

Споры благополучно решаются благодаря тому, что мы все хорошо понимаем все три стороны и мы рациональны. Хотя иногда мы можем помусолить какое-нибудь относительное простое решение неделю из-за того, что не можем договориться о том, как оно должно выглядеть или какие слова там должны быть написаны.

В итоге мы негласно пришли к модели, которую практикуют основатели Basecamp. Если мы не можем договориться, то последнее слово по дизайну как правило за мной, а последнее слово по коду — за Арнабом.

По срокам у нас обычно получается договориться без "права вето," хотя, должен признаться, сроки — это слабая сторона нашей команды. Иногда сильно увлекаемся качеством.