Як переконатися, що ваша компанія не піде під водою, якщо ваші програмісти виграють в лотерею [закрито]

У мене є кілька програмістів, вони все роблять дуже чудово і дуже розумно, очевидно. Велике спасибі.

Але проблема полягає в тому, що кожен з них несе відповідальність за одну основну область, яку ніхто інший в команді не має найменшого уявлення про те, що це таке. Це означає, що якщо когось із них вивезуть, моя компанія як бізнес померла, оскільки вони не підлягають заміні.

Я думаю про те, щоб залучити нових програмістів, щоб їх прикрити, на всякий випадок, якщо вони потраплять в автобус, або подають у відставку чи що завгодно. Але я цього боюся

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

Моє питання:

1. Як ставити це до старих програмістів, щоб вони погодилися
2. Які системи ви використовуєте для полегшення подібного роду "резервного копіювання"? Я можу зрозуміти, що ви можете зробити перевірку коду, але чи є простий спосіб провести це? Я думаю, що ми не готові до повного перегляду, реєстрація за допомогою перевірки коду реєстрації.

Як ставити це до старих програмістів, щоб вони погодилися

Представляйте їм проблему відкрито, звичайно, таким чином, що вони не сприймають це як загрозу, скоріше, можливість покращити роботу команди та проекту. Наприклад, "Я хотів би, щоб інші люди знали, що ви знаєте, якщо ви звільняєтесь" - це, очевидно, неправильний підхід :-) "Я хотів би забезпечити безперебійну роботу проекту, навіть якщо хтось із вас їде у відпустку чи захворіє. " набагато краще.

Зазвичай розробники самі відчувають проблеми щоразу, коли хтось із них перебуває у відпустці, і їм потрібно прикрити його. Більше того, хороші розробники відчувають відповідальність за проект, над яким працюють, тому вони, мабуть, погодиться з цією ідеєю. Все-таки дайте їм час на обговорення та (сподіваємось) прихильність ідеї. Також дозвольте їм сказати, як і з ким поділитися своїми знаннями всередині команди. Може виявитися, що Джо почуває себе добре працювати (і ділитися своїми знаннями) з Джимом, але не з Джеком і т.д.

Які системи ви використовуєте для полегшення подібного роду "резервного копіювання"? Я можу зрозуміти, що ви можете зробити перевірку коду, але чи є простий спосіб провести це? Я думаю, що ми не готові до повного перегляду, реєстрація за допомогою перевірки коду реєстрації.

Крім нашої команди, ми використовуємо огляди коду / дизайну

• Ротація завдань та зон відповідальності між членами команди (кожен з нас несе свої основні сфери відповідальності, але раз у раз ми виконуємо завдання у зоні, більш відомій іншому члену команди)
• Сеанси передачі знань віч-на-віч (як правило, коли необхідні вищезазначені завдання, але також перед тим, як хтось покидає команду)
• Команда / вікі проекту

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

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

Крім того, чому б просто не бути відкритим щодо цього і сказати всім, що вам усім потрібно придумати схему обміну знаннями, якщо хтось потрапив у автобус. Я не вважаю це нерозумним. Зараз це відбувається в моїй компанії, і хоча деякі з них захищаються, вони знають, що це потрібно зробити.

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

Оновлення внутрішньої документації на програмне забезпечення повинно бути першим кроком, перш ніж почати наймати нових людей. Звичайно, це означає, що ваші цінні програмісти проведуть деякий час з інструментами Office та UML замість IDE, але я думаю, що це вартує в будь-якому випадку.

Щойно у вас є поточна документація, ви можете дозволити вашим програмістам перехресно перевірити її, щоб переконатися, що всі розуміють, що написали інші. Ще не потрібно нових людей.

Тоді ви можете розглянути можливість найняти нових людей. Або ні, залежно від завантаженості вашої компанії.

Якщо ви перебуваєте у великій компанії, ви можете зателефонувати в HR та поговорити з цього питання. Повірте, хлопці з бухгалтерії мають таку ж проблему, якщо ключовий персонал потрапив у автобус. У маркетингових людей також виникне багато проблем, якщо ключовий продавець стане зомбі посеред важливих переговорів - це трапляється часто, або так мені сказали.

Я вважаю, що правильною мовою HR для цього є планування спадщини . Можливо, ваша компанія вже має політику та рамки для вирішення цього питання.

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

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

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

Однією з речей, яка робить успішні проекти з відкритим кодом настільки успішними, є відсутність коду "власності". Я маю на увазі, що ніхто не є єдиним обслуговувачем області програми - кожен може і заохочується робити внесок у будь-яку частину програми. Це те, в що я сильно вірю.

Що ви хочете зробити, - це пояснити, що те, що відбувається насправді, шкодить команді, яку ви маєте зараз. Ось пункти, які ви хочете подолати, і бажано в такому порядку:

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

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

Після того, як ви поставите свою справу там, заручтеся їхньою допомогою для отримання ідей щодо виправлення проблеми. Приходьте зі своїм, звичайно. Їхні ідеї допоможуть їм усвідомити, що вони є частиною команди, і вони потрібні не тільки для своєї області знань. Можливо, Джейн може зацікавитись тим, що робить Джо, але відчуває себе трохи заляканою. Знаючи, що може допомогти зробити передачу знань більш цікавою. Деякі речі, які ви хочете зробити, це:

• Перехресне тренування нинішньої команди. За короткий термін ви можете втратити трохи ефективності, але в одному куті програми можуть бути засвоєні деякі уроки, які можна застосувати до інших частин програми. Дайте Джейн і Джо деякий час працювати над проектом один одного.
• Сприяти культурі обміну знаннями. Компанія, в якій я працював, мала програму "коричневий торбик". Будь-який бажаючий міг представити будь-яку затверджену тему (як правило, впроваджуючи технології або програмні процеси). Компанія влаштувала обід, і ведучий отримав за свої старання пару сотень доларів.
• Наставництво має бути способом життя. Мета наставництва інших людей - звільнити вас від нових справ і робить вас ще більш цінними для компанії.
• Знайдіть способи перетнути межі інформаційного силосу, не витягаючи звання. Чим веселіше ви це зробите, тим менше загрозливо буде. Якщо люди у вашій команді такі добрі, як ви кажете, вони, ймовірно, не зовсім задоволені тим, як все відбувається. Вам доведеться бути суддею того, чи може команда впоратися з цим, але ви можете провести тиждень "давайте обираємо". Завжди починайте тут із себе. Ідея полягає в тому, щоб все ознайомитись з тим, що є "так-то-так" обов'язками, і як вони можуть вирішити проблеми, які їм краще. Поки ви почнете спочатку зі своєї шиї, вони зрозуміють, що ніхто не береться за свою роботу

Загалом, намагайтеся вразити на них, що ви хочете зробити роботу приємнішою, і вам потрібна їх допомога, щоб зробити це.

Стажисти можуть бути хорошою ідеєю, вони будуть прямими підлеглими нинішнім розробникам, тому вони не відчуватимуть загрози.

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

Я думаю, це може спрацювати.

Як правило, коли якийсь менеджер раптом починає піклуватися про документацію та планування правонаступництва, це сильний попереджувальний знак, що програмістів збирається звільнити чи звільнити. Це такий відхід від типової управлінської поведінки та турботи, що він встановлює всілякі попереджувальні сигнали у програмістів.

Кожному кажуть документувати всі свої процедури та процеси

3 рівень " Попереджувальні знаки корпоративної долі ".

В якості альтернативи, один нарис припускає, що ми б заохочували культуру " вгору чи поза ", хоча контраргументом є те, що дуже небагато компаній мають технічну драбину кар'єри, яка будь-яким чином нагадує фінансовий та енергетичний спектр, що (неправильно) управлінська драбина кар'єри містить.

Спираючись на концепцію повної документації, яку @ammoQ розпочав у своїй відповіді ...

Хороший менеджер працює над розвитком навичок їх прямих звітів, щоб будь-який із звітів міг їх замінити. Дайте своїм розробникам зрозуміти, що працівник, який забезпечує повну прозорість своєї роботи, є більш цінним, ніж той, хто зберігає всю свою роботу в таємниці та прихованому. Якщо сьогодні помер "секретний" розробник, це було б величезною відповідальністю за витрати компанії відновити втрачені знання. Якби сьогодні працівник "повного розкриття інформації" помер, компанія все ще зазнала б збитку, але це було б менш руйнівно. Тому працівник "повного розкриття інформації" має більше значення.

Будь-який працівник, який намагається зберегти приховані знання для того, щоб змусити себе бути несприйнятливим до звільнення, також робить себе незахищеним від підвищення кваліфікації. Ви не можете перевести розробника в більш складну і вигідну позицію, якщо немає кому виконати земні завдання, якими вони обтяжені сьогодні. Якщо цілеспрямовані завдання повністю задокументовані та повністю розкриті, ви можете найняти нового молодшого розробника для заповнення та просування попереднього розробника на більш високу посаду.

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

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

Або з вікі, або з 3-х кільцевою біблією документів про кожен аспект їх роботи.

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

Потім зробіть версію wiki, щоб ваш програміст міг оновлювати / редагувати / брати участь / коментувати.

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

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

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

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

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

Незабаром вони зрозуміють, що для них , а також для компанії, краще не мати одиноких людей, відповідальних за основні сфери.

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

Якщо ви розробляєте силоси, вам потрібно почати переміщення людей з одного проекту в інший. Почніть з документації, перегляду коду або виправлення простої помилки. Будь-які невеликі акти захисту коду / територіальності повинні бути вирішені, перш ніж це надто вийде з рук.

Мати одинокого спеціаліста на шматочку вашого коду - це ілюзія ефективності.

Хто-небудь хотів поїхати у відпустку?

У мене було набагато більше компаній, які потрапляють через дурні помилки керівництва. Ви не впадете і не згоріть, якщо один або два інженери відійдуть, вам просто доведеться трохи попрацювати деякий час. Шееш, я керую офшорною командою, яка кожного кварталу програє когось. Почніть рухати завдання навколо. Сьогодні