Конфликты команды разработчиков

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

Стахановец vs Бюрократ

Допустим один программист пишет код, просто пишет код, потому что JIRA полная задач. Ему нужно их сделать, кровь из носу.

А другой донимает его проблемами того что в ТЗ бардак, заказчик толком не понимает что хочет, код у нас не протестирован, не описан толком, в коммитах svn непонятно что, библиотеки используются не правильные, и вообще в проекте разруха, а никому до этого нет дела.

На самом деле не то чтобы дела совсем нет, но некогда с этим разбираться, тут работы 3 вагона. И первый программист выполняет эти задачи. Оба правы, но конфликт есть. Если принять одну сторону, то задачи сделаем, но рано или поздно проект придет в такое ужасное состояние что проще будет махнуть рукой и уйти в другой проект. Это всем знакомо, каждый разработчик наверное успел поучаствовать в проекте, в котором все было плохо поставлено.

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

Стахановец vs Изобретатель

Программист опять пишет код, просто пишет код, потому что 3 вагона еще не закончились (на самом деле он просто не видит сколько там дальше вагонов в этом составе).

А сосед придумывает какие-то хитрые схемы развития, пусть не Канзас Шафл, но на пару лет тоже хватит. С начала утверждает что вот этот метод делающий «2 + 2» никуда не годится, его нужно разбиться распределенные сервиса (для стабильности, конечно). Проходит 1 час и новая идея: надо складывать все в очередь на вычисление, периодически поднимать кластер на Amazon EC2, и там Hadoop'ом считать сумму. Потом еще подумает и скажет что Hadoop это фигня, надо на Erlang, потому что mapreduce это прошлый век, и что тут есть огромный потенциал к тому чтобы еще лучше распараллелить, но нужны особые возможности.

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

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

Бюрократ vs Изобретатель

А что если у нас столкнутся наш борец за правильность процесса и изобретатель? Для первого все идеи второго это просто саботаж. Ведь план работ уже утвержден, ТЗ написано, сроки зафиксированы. Между прочим за каждую строку ТЗ он бился часами, там все выверено. Ну какие еще новые идеи? Какие изменения на ходу? Один раз придумали, зафиксировали, и больше никаких идей! И вообще это все непроверенные технологии, их нельзя на живом проекте начинать использовать. Вот пройдет пару лет, заслужат они уважения, вот тогда можно думать. И только после того как в ТЗ внесем, до старта проекта! А сейчас все это ужасно ненадежно, все библиотеки написано черт знает кем, они не протестированы, API не задокументирован, и наверняка криво написаны. Прежде чем предлагать возьми и посчитай что это даст, подходи только с цифрами, где точной цифрой будет указан какой будет прирост производительности, или что там оптимизируем.

Да это же задушит все идеи нашего изобретателя. Вписывать в ТЗ? Писать отчеты? Проверять качество кода? Ну и что что пока не стабильно, будем перезапускать периодически. Ждать пару лет? Да так ничего не успеть, и отстать навсегда. В результате он плюнет и скажет что до него докапываются, до каких то мелочей, и нет больше изобретателя.

Конфликт

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

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