Использование соционических диад при разработке программного обеспечения

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

О сугубо логическом восприятии мира программистами ходит множество анекдотов, «настоящий программист» согласно стереотипам совершенно не приспособлен к жизни в обществе – обществе, которое является потребителем его творчества. Следствием в том числе и этого парадокса является тот факт, что более половины проектов по разработке программного обеспечения оказываются провальными: реализованный продукт не удовлетворяет потребностям пользователей. Пользователи-этики зачастую просто не могут разобраться в сложном устройстве программы.

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

Существенную помощь в решении проблемы создания программ, пригодных для пользователя может оказать использование дуальных диад. На самом деле в случае с разработкой программного обеспечения не так важно, чтобы у каждого логика был свой напарник-этик: все-таки основным исполнителем работы будут логики. Однако в случае если уже при создании программного кода будет присутствовать человек, который будет адекватно оценивать пригодность разработки для пользователей, а также и для восприятия самого кода другими разработчиками, шанс получить на выходе готовый к эксплуатации продукт, удовлетворяющий поставленным требованиям, будет существенно выше. Зачастую команда программистов, состоящая из логиков, не может даже договариваться внутри себя о понимании требований, координации усилий, о способах разработки и разделении обязанностей – все эти задачи возникают постоянно, но их решение требует этического подхода. Соответственно в случае если разработка ведется парами логик-этик, логик может сосредоточиться на написании программного кода, а этик – на добыче и переносе информации об изменениях требований в коллективе.

Идея парной разработки также не нова – этот принцип является одним из основополагающих в методологии экстремального программирования. Однако его практическое использование без учета соционических отношений приводит к неоднозначным результатам – оценка повышения продуктивности пары разработчиков относительно одного программиста колеблется от 30% повышения до более чем 100%. Те, кому «не везло» с парами утверждают, что парное программирование подходит не для всех, кому-то гораздо лучше работать самостоятельно. Другие считают, что «тот, кому не нравится работать в паре, просто никогда этого не пробовал». И то и другое по-своему верно, но без учета соционических особенностей успех попыток организовать парную разработку зависит только от удачи или «чутья» руководителя.

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

После ознакомления с соционикой и методами определения ТИМов людей я поставил следующий эксперимент: двум малознакомым разработчикам, не работавшим до этого друг с другом в одной команде и имеющим разницу в возрасте в 10 лет, я дал одну задачу на двоих. Одного из них можно охарактеризовать как предприимчивого и изобретательного, но некоммуникативного, неаккуратного и невнимательного к деталям, другой же отличается прямолинейностью и медлительностью. Уже через несколько дней совместной работы можно было заметить, что пара стала регулярно задерживаться после работы без какого-либо влияния с моей стороны, стала уточнять неточности в требованиях (против бездумного исполнения каждой буквы ТЗ), а статистика посещения развлекательных ресурсов в интернете снизилась в 5 раз. Сама задача была выполнена весьма близко к поставленным требованиям, при этом понимание и исполнение критики стало адекватным.

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

Эффект в целом можно охарактеризовать как «стали работать быстрее и качественнее». При этом люди стали работать по принципу «не знаешь – СПРОСИ», чего не всегда удается легко добиться от программистов. Проблемой, однако же, явилось то, что долгое время и последующие задачи эти разработчики также стремились выполнять вместе, хотя эти задачи вполне допускали самостоятельное решение. Однако же сам факт появления синергетического эффекта уже существенно повышает качество реализации – а, следовательно, и шансы на создание успешного продукта.

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