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

Новости

Интересные материалы: 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

Спасибо!

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