Как убедиться, что ваша компания не окажется под водой, если ваши программисты выиграют в лотерею [закрыто]

У меня есть несколько программистов, у них все очень хорошо и очень умно. Большое спасибо.

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

Я думаю о привлечении новых программистов, чтобы покрыть их, на случай, если их сбьет автобус, или они уйдут в отставку или что-то еще. Но я боюсь что

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

Мой вопрос

1. Как это поставить старым программистам, в таком они бы согласились
2. Какие системы вы используете, чтобы облегчить этот вид «резервного копирования»? Я могу понять, что вы можете сделать обзор кода, но есть ли простой способ сделать это? Я думаю, что мы не готовы к полноценной регистрации заезда с помощью проверки кода проверки.

Как это поставить старым программистам, в таком они бы согласились

Представьте им проблему открыто, конечно, таким образом, чтобы они не рассматривали ее как угрозу, а скорее как возможность улучшить работу команды и проекта. Например, «я хотел бы, чтобы другие люди знали, что вы знаете, в случае, если вас уволят» - это явно неправильный подход :-) «Я хотел бы обеспечить бесперебойную работу проекта, даже если некоторые из вас уезжают в отпуск или заболевают " намного лучше.

Обычно сами разработчики испытывают проблемы каждый раз, когда некоторые из них находятся в отпуске, и им нужно прикрывать его / ее. Более того, хорошие разработчики чувствуют ответственность за проект, над которым они работают, поэтому они, вероятно, согласятся с этой идеей. Тем не менее, дайте им время, чтобы обсудить и (надеюсь) принять идею. Кроме того, позвольте им высказать свое мнение о том, как и с кем поделиться своими знаниями в команде. Может оказаться, что Джо чувствует себя нормально, работая (и делится своими знаниями) с Джимом, но не с Джеком и т. Д.

Какие системы вы используете, чтобы облегчить этот вид «резервного копирования»? Я могу понять, что вы можете сделать обзор кода, но есть ли простой способ сделать это? Я думаю, что мы не готовы к полноценной регистрации заезда с помощью проверки кода проверки.

В нашей команде, кроме обзоров кода / дизайна, мы используем

• Ротация задач и областей ответственности между членами команды (у каждого из нас есть свои основные области ответственности, но время от времени мы выполняем задачи в области, более известной другому члену команды)
• Личные сеансы передачи знаний (обычно, когда требуется выполнение вышеуказанных задач, но также до того, как кто-то покидает команду)
• Команда / проект вики

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

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

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

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

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

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

Тогда вы можете рассмотреть вопрос о найме новых людей. Или нет, в зависимости от загруженности вашей компании.

Если вы работаете в крупной компании, вы можете позвонить в HR и поговорить об этой проблеме. Поверьте, у парней в бухгалтерии такая же проблема, если ключевой персонал сбит автобусом. У маркетологов также будет много проблем, если ключевой продавец станет зомби в середине важных переговоров - это случается часто, или мне так сказали.

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

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

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

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

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

То, что вы хотите сделать, это объяснить, что ситуация на самом деле вредит вашей команде. Вот пункты, которые вы хотите донести, и желательно в следующем порядке:

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

Лично мне пришлось иметь дело с уходящим коллегой. Хотя информационных хранилищ не было, потери все равно сильно пострадали. Шансы на это намного ниже, чем в третьем пункте выше.

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

• Перекрестная тренировка нынешней команды. В краткосрочной перспективе вы можете потерять некоторую эффективность, но в одном углу приложения могут быть извлечены некоторые уроки, которые можно применить к другим частям приложения. Пусть Джейн и Джо некоторое время будут вместе работать над проектом друг друга.
• Формировать культуру обмена знаниями. В компании, в которой я работал, была программа «Технический разговор о коричневых сумках». Любой может выступить по любой утвержденной теме (обычно знакомит с технологиями или программными процессами). Компания обслужила обед, и ведущий получил пару сотен долларов за их усилия.
• Наставничество должно быть образом жизни. Цель наставничества других людей состоит в том, чтобы освободить вас от новых дел и сделать вас еще более ценными для компании.
• Найдите способы пересечь границы информационного бункера, не поднимая звание. Чем больше удовольствия вы сделаете, тем меньше будет угрозы. Если люди в вашей команде так же хороши, как вы говорите, они, вероятно, не совсем довольны тем, как обстоят дела. Вы должны будете судить, сможет ли команда справиться с этим, но у вас может быть «давайте выберем на такой-то» неделе. Всегда начинай с себя здесь. Идея состоит в том, чтобы все посмотрели на то, каковы «такие-то» обязанности, и как они могут решить проблемы, которые у них есть лучше. До тех пор, пока вы начнете с шеи на линии первым, они поймут, что никто не собирается брать свою работу

В общем, попытайтесь убедить их, что вы хотите сделать работу более приятной, и вам нужна их помощь, чтобы сделать это.

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

По мере роста компании вам понадобятся как старые разработчики, так и те, кто сделал это после стажировки.

Я думаю, что это может сработать.

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

Каждому говорят документировать все свои процедуры и процессы

Уровень 3 « Предупреждающие знаки корпоративной гибели ».

В качестве альтернативы одно эссе предлагает, чтобы мы поощряли культуру « Вверх или Вне », хотя контраргумент состоит в том, что очень немногие компании имеют техническую карьерную лестницу, которая в любом случае напоминает финансовый и энергетический спектр, который (неправильная) управленческая карьерная лестница содержит.

Основываясь на концепции полной документации, которую @ammoQ начал в своем ответе ...

Хороший менеджер работает над развитием навыков своих прямых отчетов, чтобы любой из отчетов мог заменить их. Сделайте так, чтобы ваши разработчики поняли, что сотрудник, который обеспечивает полную прозрачность своей работы, является более ценным, чем тот, кто хранит всю свою работу в тайне и скрыто. Если «секретный» разработчик умрет сегодня, это будет огромным финансовым обязательством для компании вернуть утраченные знания. Если бы сегодня сотрудник «полного раскрытия» умер, компания все равно была бы в замешательстве, но это было бы менее разрушительным. Следовательно, сотрудник с полным раскрытием информации имеет большую ценность.

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

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

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

Либо с вики, либо с библией из трех колец документов о каждом аспекте их работы.

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

Затем создайте его вики-версию, которую ваши программисты смогут обновлять / редактировать / участвовать / комментировать.

Тогда у вас есть система, которая будет расти со временем, и будет улучшенной кривой обучения для любого нового программиста.

Кроме того, честно говоря, не стоит просто зацикливать программиста на одной основной области, это действительно стоит перепутать, перекрестную работу.

Тогда вы можете использовать свой существующий персонал, когда 1 человек уходит в отпуск или что-то в этом роде.

Каждый раз, когда один из ваших программистов заболел, звоните ему несколько раз с вопросами и проблемами.

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

Вскоре они поймут, что для них, как и для компании , лучше не иметь ни одного человека, ответственного за основные сферы деятельности.

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

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

Наличие одинокого специалиста над частью вашего кода - иллюзия эффективности.

Кто-нибудь когда-нибудь хочет поехать в отпуск?

У меня было намного больше компаний, из-за глупых ошибок руководства. Если уйдет один или два инженера, вы не рухнете и не сгорит, вам просто придется немного поработать немного. Шиш, я управляю оффшорной командой, которая теряет кого-то каждую четверть. Начните перемещать задачи вокруг. Cегодня.