Connect with us

Разработка

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

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

Анна Гуляева

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

/

     
     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Анна Гуляева
Комментарии Facebook
Продолжить чтение
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

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

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

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

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

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

Лучшие материалы о разработке и маркетинге технологических продуктов.

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

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

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

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

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

Поэтому в случае с мобильными приложениями, как правило, защищается не сам продукт, а общая идея функционирования сервиса, отражающая некоторую новизну подхода к решению той или иной задачи. Запатентовать код тоже можно, но только в некоторых юрисдикциях, например, в США или Южной Корее.

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

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

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

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

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

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

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

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

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

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

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

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

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

Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

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

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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