Connect with us

Разработка

Вы уволили лучшего разработчика. Надеюсь, вы довольны?

Продолжение спорной истории об увольнении лучшего разработчика компании: инженер Тони Робинсон разобрал объективные ошибки менеджмента, которые в итоге и привели к ситуации, описанной в оригинальной статье.

Анна Гуляева

Опубликовано

/

     
     

Продолжение спорной истории об увольнении лучшего разработчика компании: инженер Тони Робинсон разобрал объективные ошибки менеджмента, которые в итоге и привели к ситуации, описанной в оригинальной статье.

Давайте присядем, нам нужно поговорить. Если вы не читали эту историю, то прочитайте её и впитайте.

Закончили? Отлично. Давайте проанализируем её, потому что здесь скрыто намного больше. Если вы прочитали историю, вы понимаете, что автор описывает проблемного сотрудника, которого он прозвал “Рик”. Рик – это местный гений с массой специфических знаний об их продукте и ключевой участник команды разработки этого продукта.

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

Сложности с “рок-звездами” происходят почти в любой сфере работы. Может быть, в вашей сфере их называют по-другому, но рок-звезды считают, что они лучше всех и что они не должны ладить с другими членами команды. Иногда они делают качественную работу, и за это их обожают остальные, но в реальности ими сложно управлять и их сложно вписать в динамику вашей команды. Прямо как настоящих рок-звезд.

Лично я считаю, что если такие люди приходят к вам на собеседование, несмотря на то, какой у них талант, они не стоят вашего времени из-за разлада, который они вносят в команду. Это указано и в самой истории – то, как Рик игнорировал встречи и принижал своих коллег. После того, как Рик ушел, продуктивность возросла, и они объединились, чтобы спасти проект. Автор делает так, чтобы вы возненавидели Рика и сказали: “Да! К черту этого парня! Похоже, что менеджеры наконец набрались смелости и отправили эту рок-звезду погулять! Я хочу работать с этими людьми!”

Посмотрите на мою историю! Я буду использовать персонажей поп-культуры и мемы, чтобы быть ближе к аудитории!

Если вы были достаточно внимательны, в статье возникало несколько тревожных звоночков:

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

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

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

Где документация? Где встречи по обсуждению этих проблем и путей их решения?

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

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

В этой точке Рик больше похож на Тириона Ланнистера. Он умен и может решать разные проблемы.

Вскоре Рик перестал посещать встречи. У него не было для этого времени, потому что у него было слишком много работы.

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

Где были менеджеры? Где метрики? Серьезно, за время своей работы в IT и информационной безопасности я запомнил одно – менеджерам нужны показатели.

Всем было все равно, что Рик пропускал встречи? Никто не измерял количество открытых и закрытых проблем? Никто не документировал проблемы и их решение? Никто не замечал, что Рик запер себя, так как у него было все больше и больше работы?

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

На доске нашего проекта зеленые флажки сменились на желтые. Желтые – на красные. Красные огни начали мигать. Задачи постепенно оказались отложенными. Все ждали Рика.

Рик писал код быстрее, чем когда-либо. Он работал семь дней в неделю, двенадцать часов в день.

Рик брал на себя больше работы, чем он мог сделать, и вдобавок он работал по 12 часов семь дней в неделю. Никто ничего не сказал, когда заметил, что Рик находился в офисе или работал удаленно дополнительные часы, дни и недели? Менеджеры не вмешались, чтобы потребовать, чтобы Рик сделал шаг назад и задокументировал свою работу? Никто не проверил его список задач и не решил, что задания нужно распределить? Сверх того, менеджмент позволил этому продолжаться два года?

Где были менеджеры? Где были тимлиды?

Мы пригласили Рика обсудить его роль в проекте.

Как на это отреагировал Рик? Только так, как он мог отреагировать: он взорвался.

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

Представьте, что месяц за месяцем, или даже несколько лет, вас считают краеугольным камнем и доверенным сотрудником компании. Может быть, даже ответственным за главный продукт. Вы уже долгое время работаете по графику 12×7. Никто этого не ценит, а ваш объем работы только растет, пока этот монстр ужасных хаков и недокументированного кода не начинает угрожать вам, как монстр Франкенштейна.

Все в порядке. Вы все контролируете. Вы можете вернуться и исправить все позже. Вы можете убрать эти пластыри импровизации и заменить их нормальным кодом, которым вы будете гордиться. Сейчас у вас в коде есть части, которые кажутся загадкой даже вам. Мы вернемся, перепишем этот код и задокументируем его. Все, что мне нужно сделать, это довести продукт до RTM/GA, и тогда я смогу вернуться и все улучшить. Я им нужен. Моя работа важна. Мне нужно все сделать. Я не могу провалить. У нас кончается финансирование. Я не могу потерять работу.

Что если я потерплю неудачу? Как я восстановлюсь? Смогу ли я восстановиться?

И вот вас приглашают на встречу с менеджерами и говорят, что вашу работу начнут с нуля. Как вы можете отреагировать? И не говорите, что вы примете это со смирением.

Повторите?

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

Сколько дней и недель он работал по двенадцать часов? Сколько семейных встреч, дней рождения и праздников он пропустил? У него есть семья? У него есть друзья вне работы? Любимый человек? Дети?

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

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

Это чувство свободы начинает исчезать, когда ваши сбережения быстро истощаются (учитывая, что компания автора находится в Калифорнии, где нелепо дорого жить), и превращается в ужас, когда эти вопросы начинают преследовать вас:

– Найдете ли вы работу вовремя? Выдержите ли вы это? Почему они уволили вас, когда вы отдали им все? Почему никто не боролся, чтобы оставить вас в компании?

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

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

Вместо этого они вертели Риком, как хотели, эксплуатировали его талант и навыки, и, как только он перегорел, выгнали его ради продуктивности компании. Как смело и героично!

В оригинальной статье говорится, что увольнение Рика стало их лучшим решением, но в итоге они потеряли человека с огромным объемом знаний; человека, который работал с клиентами над созданием прототипов – а в итоге кончилось это тем, что под жалобы на плохой код Рика они выпустили посредственный продукт с еще большим количеством костылей. Они совершенно забыли о том, какое бремя нес этот человек, чтобы сохранять все в рабочем состоянии.

Вместо того, чтобы создать историю о том, как они остановили падение человека при помощи вмешательства, выдающейся командной работы и грамотного руководства (что действительно нужно людям из IT), они решили рассказать о токсичной среде и проблемах, причиной которых, как казалось, был Рик. Вместо того, чтобы затронуть корень проблемы, они решили применить быстрое и простое решение. Что и следовало ожидать.

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
3 комментария

3 Comments

  1. Глеб Ткачук

    18.10.2017 at 17:35

    Тут что-то пошло не так. При переходе по ссылке все нормально https://uploads.disquscdn.com/images/e184b971787f93c639b07c18f9ee9e4f0be93116974c2ecdb4ac27dd3665e05d.png

You must be logged in to post a comment Login

Leave a Reply

Новости

Digest MBLTdev: Новости для iOS разработчиков №147

В течение недели топовые iOS-разработчики Руслан Гуменный, Саша Черный и Саша Зимин, а также директор по продукту VK Иван Козлов собирают для вас интересные и полезные ссылки на статьи, необходимые для прочтения каждому начинающему и опытному разработчику. В каждом выпуске – новости, коды, инструменты, дизайн и прочее.

e-Legion

Опубликовано

/

Автор:

AlphaZero показывает невероятные успехи в выигрывании чего угодно у кого угодно. Стандарт C++17 перешёл в статус Published. Успели-таки, чертяги. Microsoft замутит ноутбуки на ARM. Наше восхищение рэдмондцам. Это должно продвинуть индустрию вперёд. А ещё, редакция дайджеста получила ваши ответы. Они нас порадовали. Прямо подарок к Новому году. Спасибо. Потребуется какое-то время, чтобы реализовать задумки, но мы, что называется, on the way.

1

31 Million Client Registration Files Leaked by Personalized Keyboard Developer

Есть такая популярная сторонняя клавиатура — AI.type. Немножечко обнаружилось, что эта клавиатура собирает прорву данных, да ещё и хранит их небезопасно на своём сервере. Кстати, покупая какую-нибудь китайскую розовую клавиатуру с радужной подсветкой всего за 99 руб., будьте готовы к похожему результату.

MACKEEPERSECURITY.COM

Apple Expands Search Ad Offerings with Search Ads Basic

Новый тип рекламы в App Store. Пока только US.

WWW.MACSTORIES.NET

4

Hyperion-iOS

Штука для дизайн-ревью приложения прямо на девайсе. Можно измерять расстояния, смотреть атрибуты и замедлять анимации без Xcode.

GITHUB.COM

Singleton, Service Locator and tests in iOS

Статья про антипаттерны Singleton и Service Locator, а также про то, как можно оставить их в проекте и иметь тестируемый код.

BADOOTECH.BADOO.COM

Building an enum-based analytics system in Swift

Аналитики в современных приложениях много. Маркетологом только дай волю. 5+ систем воткнут только так. Вот вариант, как оформить хаос с событиями. А если вы используете MVVM, поглядите этот вопрос на SO, тоже про усмирение хаоса.

WWW.SWIFTBYSUNDELL.COM

When Not to Use an Enum

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

MATT.DIEPHOUSE.COM

e-Legion Meetup: дизайн мобильных интерфейсов

Санкт-Петербург, 14 декабря, офис Тинькофф, 18:30. «Система контроля версий для дизайнера» от Димы Головкова из e-Legion. «Дизайн форм для мобильных приложений и сайтов» от Ника Бабича из UX Planet. «Как мы используем продуктовую мобильную аналитику» от Толи Ларина из Тинькофф. Будет трансляция.

ELEGION.TIMEPAD.RU

Moscow CocoaHeads Meetup

Москва, 15 декабря, офис Mail.Ru, 19:00. «Как стать GPU-инженером за час» от Андрея Володина из Prisma AI. «Распределённая сборка IPA» от Мити Куркина из Mail.Ru. «Синее смещение: оптимизация запуска на платформе iOS» от Виктора Брыскина из Яндекса.

CORP.MAIL.RU

c71bdfcf-9da6-4069-9426-b03ba710c042

Яндекс изнутри: глазами iOS-разработчика

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

WWW.YOUTUBE.COM

Предыдущие выпуски Digest MBLTDEV и подписка доступны на официальном сайте. Всё бесплатно и никакого спама, честно!

Комментарии
Продолжить чтение

Медиа

Android Dev Подкаст. Выпуск 51. Разработка прошивок. Откровения ROMоделов

Необычный выпуск, где не обсуждаются DI, Kotlin и MVP – в эфире суровые ребята с xda-developers, которые уже не первый год занимаются написанием прошивок для девайсов, в том числе для всех трех Yotaphone и головных устройств Yandex Auto.

Леонид Боголюбов

Опубликовано

/

Необычный выпуск, где не обсуждаются DI, Kotlin и MVP – в эфире суровые ребята с xda-developers, которые уже не первый год занимаются написанием прошивок для девайсов, в том числе для всех трех Yotaphone и головных устройств Yandex Auto. Выпуск подойдет всем, в том числе незнакомым с разработкой Android. Много интересного материала: от откровений про сборку образа в течении 15 часов и обсуждения безопасности кастомных прошивок до обзора рынка вакансий framework-разработчиков и устройств, которые у них лежат в карманах.

Обсудили:

  • Что вообще такое ROM, программатор, bootloader, fastboot, кирпич, AOSP, кастомные сборки, Custom Recovery, dalvik cache, deodexed
  • Для чего это делают, что движет людьми на Xda
  • Где статьи и разработчики framework обитают
  • Что нужно, чтобы начать этим заниматься
  • Для каких устройств проще создавать сборки
  • Что с Cyanogen сейчас
  • Почему вендоры плохо поддерживают обновления старых устройств, порой хуже энтузиастов с Xda
  • HAL
  • Project Treble
  • Какие тулзы для разработки
  • Сколько времени сборка
  • Почему в логах на устройствах так много мусора
  • Сертификация Google
  • Повышение, понижение безопасности
  • Механизмы обновления ОС на устройствах пользователей
  • Есть ли работа и вакансии для вашей профессии
  • С какими устройствами ходят разработчики Yotaphone
Комментарии
Продолжить чтение

Разработка

Интересные материалы для разработчика мобильных приложений #193 (4-10 декабря)

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

Леонид Боголюбов

Опубликовано

/

8 учебных проектов

Предлагаем 8 вариантов проектов, которые можно сделать «по фану», дабы получить реальный опыт разработки.

Зачем я купил Mac Mini (Late 2012) накануне 2018 года?

После смены старого MacBook Pro на еще более древний Mac Mini, объем оперативной памяти увеличился с 8 GB до 16 GB и маленький 13” экран сменился на два 22”. Осталось разобраться с производительностью.

14-й опрос Developer Economics

Этот опрос создан разработчиками для разработчиков и прольет свет на будущее индустрии программного обеспечения.

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 Устройства, IoT, AI

Комментарии
Продолжить чтение

Дизайн и прототипирование

Hyperion

Hyperion – встраиваемый в iOS-приложения плагин, помогающий контролировать верстку.

Леонид Боголюбов

Опубликовано

/

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

  

 

 

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

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

Популярное

X

Спасибо!

Теперь редакторы в курсе.