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

Начнем мы с истории про навязывание конкретного решения без понимания всей глубины проблемы, а часто и вообще без понимания сути проблемы. С подобной ситуацией наверняка сталкивался каждый. На очередной ретроспективе, просто в разговоре или при обсуждении дизайна один из разработчиков предлагает выкинуть к чертям технологию X и внедрить вместо нее технологию Y. По его словам, всем в проекте станет жить гораздо легче и проблем станет на порядок меньше. Причем, в детали он особо не вникает и обсуждать готов только на поверхностном уровне.

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

В чем тут проблема и почему такое происходит? Продукт (его архитектура, технологии, фреймворки, код) развивается со временем в попытке удовлетворить требованиям заказчика. В процессе этой эволюции какие-то решения отмирают, а какие-то остаются от безысходности или исторически. И это нормально. Любое изменение должно быть связано с конкретным требованием или же с проблемой. В случае проблемы, ее нужно детально разобрать, обсудить и докопаться до корневых причин. И только тогда можно предлагать конкретное решение. Решение, которое не основывается на реальных проблемах, обсужденных всеми сторонами, по сути бессмысленно. Оно может привести к еще большим проблемам, но в другой области.

Еще, любое изменение требует ресурсов, будь то время, человеко-часы или деньги. И тратить эти ресурсы нужно максимально эффективно для бизнеса. Менять X на Y может быть банально невыгодно, несмотря на пользу в долгосрочной перспективе от нововведений. Команда может потратить большое количество времени на изучение и получение практического опыта в новой технологии, наступить на все возможные грабли, обильно раскиданные в этой области. А это может привести к краху и проблемам на проекте.

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

Откуда же берутся такие разработчики и их “подрывные” идеи? Зачастую они берутся из публичных источников. У разработчика может быть приятель, который давно работает с технологией Y и постоянно давит своим авторитетом и опытом. Это может быть статья на публичном источнике, в которой во всех красках описывается Y и какое счастье она несет другим командам. Это может быть конференция, где Y успешно продали в выступлении. Или даже соседняя команда, с которой разработчик общается в курилке. Любая идея хороша, если применяется к правильным проблемам правильными людьми. И не более чем.

А дальше додумывайте сами…