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

Новости

Интересные материалы: 18.07

У нас код полета на Луну, голосовые интерфейсы и эпические фейлы.

AppTractor

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

/

Автор:

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

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

Разработка

Сколько стоит разработка мобильного приложения?

Ждет нас покупка авто или ремонт холодильника, мы всегда спрашиваем о стоимости. И хотим услышать конкретную цифру. Наши клиенты тоже ожидают конкретики: «Разработка стоит X рублей». Но возможно ли такое?

Magora Systems

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

/

Автор:

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

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

Уточнение

Чем точнее требования, тем меньше шанс, что вас поймут неправильно. И тем точнее получится оценка стоимости разработки. Поэтому мы планируем звонок, чтобы обсудить:

  • Бизнес. Спрашиваем: для кого делаем приложение, каковы потребности аудитории. Уточняем ключевые функции, желаемые сроки и бюджет. Выясняем, какую проблему решит приложение, и как поможет вам зарабатывать или экономить. Даем первичную оценку – можно ли вообще реализовать проект за выделенную сумму? Например, сделать сервис такси с нуля за 200 тысяч рублей просто невозможно.
  • Техническую сторону. Это про охват (влияет на архитектуру), объемы данных, платформы (iOS, Android, Web?), устройства (смартфоны, планшеты, гаджеты?), интеграцию с другими сервисами (Google Maps и др.) и т.д. А еще узнаем о предпочтениях в дизайне.

Анализ

Назначаем опытного специалиста. Он изучает все, что предоставите: техническое задание, описания, прототипы, сценарии использования и т.д.

Бывает, есть только идеи или общие описания. Бывает, есть какое-то ТЗ, но почти всегда данных недостаточно для оценки. Поэтому сначала мы и уточняем детали.

Если возможно, после разговора выделяем список функций, оцениваем каждую и подбиваем итог. Эту работу мы делаем бесплатно и отправляем КП через 1-3 рабочих дня. Предупреждаем, что стоимость может измениться. Фиксирована только та цена, которая указана в контракте.

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

Оценка стоимости разработки

Изучив входные данные, мы разделим объем работ на блоки и оценим. Если функций много и проект масштабный, предложим выделить и начать с MVP (базовой версии). Так вы быстрее выпустите продукт, чтобы проверить «в бою» и собрать отзывы пользователей.

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

Чтобы ускорить оценку, у нас есть список стандартных функций с установленными трудозатратами. Это не цифры «с потолка», а результат опыта и реальных проектов.

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

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

Что-то пошло не так…

Исследование Standish Group agency показало, что только 3% крупных проектов и около половины малых проходят по плану. Как же так?!

Разработчики не умеют оценивать?

Не совсем. Зачастую оценивают идеальный сценарий.

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

А потом вы решаете добавить 2 функции. Но их не оценивали, надо пересчитывать. И да, цена вырастет.

Конечно, причины бывают разные, суть в том, что непредвиденные ситуации возникают в 97% проектов.

Зачем вообще оценивать?

Несмотря на все сказанное, вы:

  • Узнаете условия и примерную стоимость функций, которые нужны.
  • Проверите компанию: как наладили контакт и что подготовили?
  • Оцените профессионализм: какие задают вопросы, есть ли релевантный опыт, заинтересованы в проекте?
  • Увидите оперативность: если сейчас отвечают через неделю, что будет дальше?

Как получить максимум от оценки

  • Узнать ставку часа. Если ставкая высокая, а общая сумма – нет, что-то могли упустить при оценке.
  • Посмотреть, есть ли в команде тестировщики, аналитики, менеджеры. Чтобы сделать продукт, мало просто написать код.
  • Подробно описать проект. Дать ТЗ, макеты, схемы… Чем четче требования, тем точнее оценка.
  • Перепроверить, что оценили все функции, которые хотите получить в приложении.
Комментарии
Продолжить чтение

Разработка

DevOps на службе разработки ПО и Open Source

Всего за несколько лет разработка ПО превратилась в стратегический сектор ИТ-индустрии и экономики в целом, особенно во Франции, если верить недавно представленным планам широкомасштабной цифровизации. Карин Браун-Энно, управляющий директор Red Hat France, рассказала нам о роли DevOps в росте индустрии.

AppTractor

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

/

Автор:

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

Именно поэтому методология DevOps приобретает все более значимую роль, а ее использование в корпоративном секторе только растет. Истоки DevOps лежат в стремлении полностью преобразовать методы и процессы создания и развертывания приложений с целью кардинально повысить их динамичность и улучшить взаимодействие участников. DevOps (акроним от англ. development и operations – разработка и эксплуатация) предлагает разработчикам и специалистам по эксплуатации ИТ-систем быстрый и не требующий лишних усилий подход к запуску новых или улучшенных приложений, позволяющий делать это быстрее и эффективнее.

Поскольку ключом к повышению динамичности является открытость и сотрудничество всех участников процесса производства ПО, принципы и технологии Open Source оказываются здесь как нельзя кстати. В частности, мировые интернет-гиганты и инновационные французские компании едины во мнении, что благодарягибкости и простоте интеграции с имеющимися ИТ-средами, решения с открытым кодом заметно выигрывают на общем фоне, помогая облегчить взаимодействие на всех этапах разработки и развертывания проектов DevOps.

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

Почему DevOps?

Одна из главных причин возникновения концепции DevOps – это стремление к непрерывности, причем, непрерывности не только самих ИТ-сервисов, но и их совершенствования и доработки силами разработчиков и заказчиков в лице представителей бизнеса. Очевидно, что, сводя к минимуму перебои в работе ИТ-сервисов, можно автоматически максимизировать результаты работы компании. Однако, постоянно улучшая взаимодействие с пользователем (исправляя ошибки и запуская новые функции, которые тестируются в «боевых» условиях и при необходимости очень быстро дорабатываются), ИТ-подразделение также оказывает весомую поддержку своему предприятию, предоставляя ему средства для реализации и моделирования бизнес-стратегий, ориентируясь на поведение рынка, которое отслеживается в режиме близком к реальному времени.

Компания Puppet Labs отмечает, что 63% организаций, внедряющих DevOps, делают это для повышения качества развертывания, примерно такой же процент опрошенных хотят повысить частоту доставки, а 61% респондентов прежде всего фокусируются на улучшении качества процессов.

И это еще не все. Экспоненциальный рост обмена данными в результате пришествия интернета вещей вынуждает практически полностью пересмотреть модели обработки данных и связанные с этим приложения. Умные бытовые приборы и носимая электроника, финансовые услуги, автономные автомобили, системы управления воздушным движением, промышленность нового поколения (т.н. «Индустрия 4.0»), цифровое управление цепочками поставок – уже становятся обыденностью, охватывая значительную аудиторию за счет оптимизации фундаментальных процессов. Основываясь на новых методах обработки огромных объемов данных (структурированных и неструктурированных) и включая в себя расширенное и автоматизированное управление корпоративными процессами с охватом партнеров и клиентов, и эти модели интероперабельности, гибкости, сотрудничества, совместного использования и, прежде всего, инноваций лежат в основе модели Open Source, формирующей информационные системы следующего поколения.

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

Сегодня у нас есть все, чтобы вывести эволюционировавшие процессы сотрудничества в фазу зрелости. Решения IaaS («инфраструктура как услуга») и PaaS («платформа как услуга»), лежащие в основе модели DevOps, предлагают разработчикам гораздо больше гибкости и свободы, позволяют создавать новые приложения быстрее и с меньшими усилиями, облегчают развертывание приложений, устраняя барьеры и повышая управляемость. Переходя на язык конкретики, IaaS на основе OpenStack и PaaS с открытым кодом дают возможность быстро и итеративно разрабатывать облачно-ориентированные приложения, построенные на основе микросервисов (базовых компонентов приложений), объединенных в рамках супер-обновляемой модели, предоставляя все необходимые ресурсы и полностью отвечая целям DevOps.

Android Dev Подкаст. Выпуск 54. DevOps

С учетом выше сказанного неудивительно, что DevOps все чаще находит благодатную почву в последних ИТ-разработках, как инфраструктурных, так и ориентированных на обработку операционных данных, возникающих в ответ на стремление организаций повысить конкурентоспособность в погоне за лидерами отрасли. Став синонимом инновационной и ориентированной на сотрудничество методологии, DevOps отлично вписывается в мир Open Source, который активно осваивает и развивает облачные технологии, мобильные вычисления, большие данные и другие актуальные инновации.

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

Новости

Microsoft и National Geographic выделяют гранты на разработку экологического ИИ

Microsoft и National Geographic запускают программу грантов объемом в $1 млн для разработки искусственного интеллекта в сфере экологии.

AppTractor

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

/

Автор:

Как пишет “Хайтек”, в рамках проекта от 5 до 15 разработчиков получат финансирование, доступ к облачным инструментам Microsoft и инструментам для машинного обучения, а также консультации экспертов National Geographic Labs и National Geographic Explorer.

Мы считаем, что люди и компьютеры, работающие вместе при помощи искусственного интеллекта, могут изменить отношение к экосистеме Земли, а также контролировать и моделировать ситуацию в экологии, — рассказал главный экологический эксперт Microsoft Лукас Джоппа.

Компании смогут получить гранты до 8 октября 2018 года. Для работы с Microsoft и National Geographic разработчики должны работать в сфере изменения климата, сельском хозяйстве, загрязнении водоемов или вымирании различных видов животных. Любые нейросети, разработанные на деньги с грантов, должны быть с открытым исходным кодом, чтобы любой исследователь мог использовать эти инструменты.

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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