Проблемы современной разработки. Часть 4: Кампитенции
Почему вашим программистам нужно объяснять постановку и почему ваши задачи не решаются по щелчку. Суровая правда жизни, снова.
Предыдущие части: первая, вторая, третья.
Потерянный рай
1994й год, Silicon Valley, суперсовременный офис ИТ-корпорации, переговорная комната.
С одной стороны сидят четверо серьезных мужчин в дорогих костюмах: CEO, COO, CFO, CTO, с другой — непонятный чувак с патлами и в косухе.
— Джон, вы признанный эксперт в электронике и компьютерах, мы хотим нанять вас для создания нашего нового флагманского продукта: первого в мире электрочайника.
(протягивает через стол кейс забитый долларами):
— У вас есть 9 месяцев на все, через 9 месяцев продукт должен быть на рынке.
— Мы верим в тебя, сынок. С богом!
Самое веселое что нечто подобное действительно было и практиковалось в Силиконовой долине на ранних этапах ее истории.
Что нашло отражение в массовой культуре в виде образа «всемогущего ит-эксперта», которого достаточно нанять за безумные деньги и он все починит:
Современность
Да, на свете действительно и поныне существуют программисты, которым не надо объяснять что нужно делать, достаточно лишь обрисовать задачу в общих чертах.
Выглядят они как-то так.
В случае просто разработки ПО — ну например так.
Шанс на найм такого кадра, его желание с вами сотрудничать и требуемый бюджет думаю сами оцените.
Поэтому спустимся на грешную землю, где обитают обычные офисные жопоголовые криворучки разработчики и погрузимся в их скотскую реальность, полную боли, страдания и унижений.
Мотивация
Которой нет у ваших обычных офисных программистов.
офисный софт — тоска смертная и уныние, заниматься им с реальным (а не показушным) интересом и годами могут единицы.
Которые очень быстро уходят либо в аналитики либо в менеджмент.
Всю жизнь ваять CRUDы и шлепать формы — что угодно, но не пик карьеры и не мечта программиста.
Если было профильное образование, с элементами CS, т.е. человека несколько лет учили что такое алгоритмы, структуры данных и как это все вообще работает — заниматься потом формошлепством для него это чистый декаданс.
Примерно как пилота истребителя сразу после летной школы отправить в пехоту рыть окопы.
Поэтому какого-то особого желания ковыряться в вашем проекте у обычного офисного разработчика нет и быть не может.
Командный дух
Которого тоже нет, потому что вы все работаете в коммерческой компании, за зарплату и без возможностей роста для разработчиков — банально некуда.
Вы конечно можете организовывать какие-то слеты на природе, с гитарой и шашлыками — концептуально это ничего не изменит.
Карьерных перспектив для разработчиков в компании, если она не айтишная, не занимается продуктовой разработкой — нет.
Как только уровень компетенций вырастает выше требуемого в компании уровня, а это происходит достаточно быстро, за 3-5 лет — все, дальше такому сотруднику придется уходить.
Это и есть основная причина текучки кадров.
Уважение
Его внезапно тоже нет (откуда?) — чтобы глубоко разбираться в том что делает например банковский софт, нужно внезапно профильное финансовое образование, нужно быть банкиром.
Все тоже самое с CRM/ERP и любым другим софтом для автоматизации бизнеса — нужно иметь соответствующий бекграунд, а не один только голый навык программирования чтобы в нем ориентироваться без детальной постановки задачи.
Очевидно что вот такие «слепые котята», стукающие лапками по клавиатуре не могут вызывать уважение у остальных коллег, особенно когда те узнают о зарплатах «котиков».
В итоге и получается, что в большинстве случаев на работе вы имеете дело не с реальными профессионалами, а со «слесарями по компьютерам», которым действительно на каждый чих нужно подробное объяснение и инструкции.
Так это сейчас устроено и так работает.
Другой вариант
На самом деле есть другой путь, которым вы можете имея в голове лишь абстрактное описание и мешок денег - получить в итоге работающий софт.
Называется заказная разработка.
После заключения контракта, к вам приедут специальные люди в белых халатах называемые аналитиками и проведут опрос, заодно предложат несколько вариантов по реализации исходя из предыдущего опыта профильных проектов.
Через примерно месяц будет составлен документ под названием «Техническое задание», содержащий полное поэкранное описание создаваемого проекта.
Дальше уже по этому документу будет реализована сама система, которую вы так хотели.
Без вашего участия, без погружения в детали.
Итого
Если уж вы полезли в это дерьмо — наняли себе разработчиков в штат и чего-то от них хотите, увы но вам придется натурально их «пасти», придется писать детальные постановки, по определенным правилам и придется отслеживать выполнение работ.
По-сути вам придется делать часть работы вместо ваших нанятых разработчиков, оставив им лишь само написание кода, но не постановку или контроль.
Так устроен современный массовый ИТ и таковы его реалии, увы.