Здравствуйте, меня зовут Дмитрий, это моя первая статья, не ругайте сильно
Рано или поздно в любой компании, стартапе возникает "Башня знаний" - если нет передачи знаний, часто возникает ситуация, что один программист закреплен за одним направлением, и только он знает, как там все реализовано, документация не ведется, GIT не используется, в лучшем случае можно уточнить у программиста, что и как. И если вам повезет, он будет даже почти свободен, сможет рассказать вам о том, что есть. В худшем он уже не работает и проще написать все заново, чем разобраться с кодом.
Каждый менеджер много раз в своей практике слышал “этот код писали криворукие обезьяны, все сделано через Ж, никто в этом не разберется, нужно писать все с нуля”. В целом это удобно и выгодно, если вы интегратор, но не более.
Итак, у нас есть Башня знаний, что теперь с этим делать и кто помимо нее еще существует?
- Введем аббревиатуру, чтобы было проще: Башня знаний – БЗ
- Стрелок - защитник Башни, как правило это IT директор, проект менеджер, руководитель, который знает давно БЗ, верит в него или просто видит, что БЗ дает результат.
- Но нужно понимать, что он дает результат только в том направлении, где он все знает, и результат, вменяемый по срокам, дает только он.
- Человек в черном - хочет изменить ситуацию, как правило это IT директор, менеджер проектов (да, такое тоже бывает, я про такое слышал, мне знакомый знакомого об этом рассказывал), TeamLead, и ведущий программист, ему нужно понимание, что происходит на проекте, как можно масштабировать и можно ли вообще это сделать. Во время отпуска БЗ сможет ли кто-то его заменить и тд.
- Сияющие - универсалы, мультиязычные программисты, это те программисты, которые могут сайт сделать, приложение под мобильное устройство, blockchain, и тд. Если вы узнали себя или кого-то из своей команды, то не обольщайтесь, они вам не помогут, как правило, такие программисты хорошо знают алгоритмы, хорошая логика, но БЗ в предметной области знает больше. Да, в итоге они смогут разобраться, что и как, но это дополнительное время, не факт, что они увидят всю картину и заложенный функционал и что-то не поломают в процессе небольшой доработки / правки.
Возможно, вы сами Башня знаний? И думаете сейчас, что вы смогли обмануть систему и знаете, как противодействовать всем переменам, без вас компания не сможет существовать, увы, вынужден вас огорчить, вы не царь и бог на проекте.
Итак, кейсы:
P.S. все имена изменены на мое, чтобы никому не было обидно. Надеюсь, они это не увидят.
1) Частная компания (7-8 человек, это вместе с директором, бухгалтером и т.д.). Наш герой Дмитрий, хороший программист, феноменальная память, Lead на проекте, проекту 5 лет, есть заказчики и все вроде хорошо, проект развивается, но он любит прибухнуть, пропасть на пару дней, прийти на работу немного нетрезвым.
Проблемы:
1. Может пропасть, не выходит на связь. Тут без комментариев.
2. Может нетрезвым прийти на работу, в лучшем случае спит и не ищет переключений. Может кодить, и даже будет работать (честное слово, сам видел), но через пару дней будет в офисе стоять мат, кто это писал и как это работает? Причем часто эти вопросы задает сам БЗ.
Решение, которое было принято:
БЗ был уволен, наняты другие программисты, которые с нуля переписывали весь функционал на другом языке программирования, и вели всю документацию по проекту. Решение дорогое, по деньгам и срокам, но на такое решение часто идет бизнес, когда нет другого варианта и не получается решить вопрос по-другому.
Всем тем, кто решил, что он нагнул систему и без него теперь никак, посвящается.
2) Дмитрий из энтерпрайза, хороший программист, стабильный, тихий, не сильно общительный, давно в компании, и самое главное, отвечает за 2 направления, ну как отвечает, ему их дали и он там один, более 2-3 лет он их пилит, дорабатывает, улучшает, и закрывает тикеты с багами.
Проблема:
Вроде бы все хорошо, есть лояльный сотрудник, который давно в компании, знает предметную область. Но компания растет, и Дмитрий становится начальником отдела группы разработки, и это хорошо. Если он делегирует данные задачи, то у него нет времени на помочь и рассказать, как все работает, в итоге после нескольких подходов к нему он говорит, что сделает эту задачу сам чуть позже. Или программист ищет, где это исправить самостоятельно, тратит много времени (менеджер не сильно доволен, Дмитрий же эти задачи быстро решал), может случайно все уронить.
Решение, которое было выстрадано (страдания еще идут):
Было реализовано SVN центральное хранилище, попытка как-то все структурировать, и на этом все.
Да, в кровавом энтерпрайзе часто главное, чтобы работа шла и задачи решались быстро. Вся работа идет по SRS и заявкам от пользователей, через три года проще все переписать с нуля.
Нельзя получить, делая каждый день одно и то же, новый результат.
3) Дмитрий из энтерпрайза, хороший парень, всегда поддержит компанию, подскажет, куда развиваться в его направлении, умный парнишка. Любит работать по "итальянской забастовке".
Проблема:
Не любит решать задачи, просит аналитиков расписать все задачи, после этого просит расписать низкоуровневые задачи вплоть до типа полей и как будет все взаимодействовать, после этого, а что вы мне написали? У меня так работать не будет. Раз в полгода или год увольняется, чтобы получить финансовое предложение получше.
Решение:
Регулярные втыки от руководства работают, но недолго. Было нанято несколько падаванов в помощь (мы помним, в начале было, что любит учить). Итог: есть несколько человек, которые владеют областью. Падаваны ведут всю документацию, да, они пока падаваны, но лучше что-то, чем ничего.
Объединяет все три кейса то, что нет передачи знаний в компании, не ведется даже верхнеуровневая документация, изменения есть вроде как в таск менеджере, но их, пока будешь разбирать и смотреть, потратишь много времени.
Должно быть, Желательно:
- Обмен опытом раз в неделю, если команда более чем из 3х человек, пятница, пицца, пиво и мини лекции по реализованному нестандартному функционалу, это позволит поднять общий уровень квалификации коллег и узнать про узкие места, если они есть.
- Ведение документации, пускай верхнеуровневой, но хотя бы что-то.
- Комментирование всего нестандартного функционала, через год мало кто из программистов вспомнит, что он программировал и почему именно такое решение было реализовано в итоге.
Спасибо за внимание.
