Connect with us

Разработка

Мы уволили нашего лучшего разработчика – и это стало нашим лучшим решением

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

Анна Гуляева

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

/

     
     

Почему увольнение главного разработчика компании стало её лучшим решением? Мы перевели популярную историю, в которой один из сотрудников рассказал, как получилось так, что вся работа по проекту велась одним безумным гением, и в итоге затянулась на несколько лет.

“Вы никогда не поймете что-то из того, что я сделал. Я Альберт, [чертов], Эйнштейн, а вы все обезьяны, копающиеся в дерьме”.

И так наш местный гений, наш доктор Джекил, полностью превратился в мистера Хайда.

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

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

Эта история посвящена одному очень одаренному члену нашей команды с глубоким пониманием архитектуры продукта. У него была сверхъестественная способность прогнозировать будущие потребности и тонна специфических знаний об отрасли.

Он был нашим главным сотрудником. Он убивал наш основной проект.

Назовем этого человека Риком.

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

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

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

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

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

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

У Рика рос бэклог. В инструментах, созданных им прежде, возникали баги. Они отвлекали его внимание от требований по созданию нового продукта.

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

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

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

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

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

День за днем Рик становился все агрессивнее и изолированнее. Джекил становился Хайдом.

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

Меня послали, чтобы узнать, можем ли мы спасти проект. Моя первая встреча была вышеупомянутой встречей с “Альбертом Эйнштейном”.

Я открыл исходный код. Рик был прав: никто не мог понять то, что он создал. Кроме него. Этот код был воплощением его разума. Что-то было очень умно, что-то было большим количеством копипасты, все было очень своеобразным, но ничего не было задокументировано.

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

Мы пригласили Рика обсудить его роль в проекте. Мы рассказали о своих опасениях. Мы пропустили его сравнение с Альбертом Эйнштейном.

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

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

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

Мы уволили Рика. За неделю всё немного успокоилось. Шокированной команде понадобилось время, чтобы прийти в себя после потери своего гуру.

Затем я увидел, как они столпились у доски. Они объединялись. Они создавали новый продукт. Он будет гораздо проще. В нем не будет много функций, но он не потребует ещё пяти лет для создания.

Продукт Рика поддерживал динамический рабочий процесс с более чем пятнадцатью тысячами вариаций. На самом же деле 99% наших кейсов использования следовали одному из трех путей. Команда жестко закодировала рабочий процесс. Это позволило удалить более 30% работы Рика.

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

Они убрали сотни часов работы Рика. Но они убрали и тысячи часов технического долга.

Мы достигли соглашения со спонсором о прекращении работы над некоторыми функциями. Они были полезны только 5% группы пользователей, но составляли четверть сложности продукта.

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

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

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

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

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

Мастер строительства – это хорошо. Но небоскребы строят команды.

Его присутствие было разрушительным.

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

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

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

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

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

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

 

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

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

2 Comments

  1. Сергей Шинкарёв

    17.10.2017 at 11:42

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

    Коллеги, зачем вы тратите время на такие поверхностные материалы?

    • AppTractor

      17.10.2017 at 11:47

      Ну так “полный набор” не отменяет происходящего и необходимости избегать таких ситуаций, нет? А вообще “хайпанули немножко”, да :)

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

Спасибо!

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