Неэффективный менеджер – 2. Денис Павлович Демахин
Рефакторингом можно заниматься бесконечно, и для заказчика, который выделяет деньги, всё будет выглядеть так, как будто программист страдает какой-то хренью. Тратит время без всякого результата, не выпускает никаких релизов.
То есть, рефакторинг – это насыщение внутренней энергии системы. Эффективный менеджер быстро пишет код, чтобы он только работал. Он идет по головам, он хардкодит. Он выглядит круто – очень быстро выпускает релизы. Очень эффективная и эффектная работа. Неэффективный менеджер рефакторит, насыщает внутреннюю энергию системы, чтобы следующим программистам было проще. Всё это повышает затраты на разработку.
2. Незаменимость программиста, написавшего непонятный код.
Это делает уход программиста крайне нежелательным для компании. Поэтому у IT-шников такие высокие зарплаты. Во-первых, их стараются удержать. Во-вторых, возникает огромные требования к квалификации IT-шников, т.к. они должны всё-таки как-то разобраться в предыдущих нагромождениях. Значит, нам тут нужен обязательно только СУПЕР-АЙТИШНИК, только такой не повязнет насмерть в этом болоте и покажет результат. А суперский хочет много денег. Вот и дергают их с одной работы на другую. В результате этой войны за кадры IT-шники еще и постоянно мечутся туда-сюда между компаниями, усугубляя эту ситуацию. Системы только больше и больше уродуются. А вот с программистом, написавшим чистый код, можно попрощаться легче, ведь его проще заменить.
Эта ситуация создала постоянную незаменимость и крайнюю востребованность IT-шников сильнее джуниоров. Джуниоры как раз особо никому не нужны, потому что они могут только написать свой код, но не могут понять чужой. А ценится как раз второе.
И что с этим всем делать?
1. Первому лицу понять, что нужно нанимать программистов не только квалифицированных, но при этом и идейно правильных. Хотя бы самого главного.
2. Первому лицу работать над собственной квалификацией в IT. Не имеется в виду программирования, а понимание самого понятия технического долга.
3. Первому лицу выделять ресурсы на рефакторинг, на написание User stories, детальных блок-схем, на написание инструкций не только по пользованию системой, но и по ее программированию.
4. Главному айтишнику выбивать ресурсы на качество кода.
5. Остальным айтишникам заботиться о судьбе систем и коллегах по цеху, чтобы им было проще. Будет лишний повод для гордости.
Глава 3. Мой самый короткий аудит
На производственном предприятии, где я работал, было так заведено, что производственные участки не доставляли сделанную работу на дальнейшие этапы. Они просто сигнализировали, что их часть работы сделана. Всю перевозку между участками производили два транспортировщика, которые находились в планово-диспетчерском отделе (ПДО). Они и забирали и отвозили.
И было у всех такое смутное ощущение, что что-то как-то всё замедляется через эту службу транспортировщиков. Что все их