Books-Lib.com » Читать книги » Домашняя » Как хорошему разработчику не стать плохим менеджером - Константин Борисов

Читать книгу - "Как хорошему разработчику не стать плохим менеджером - Константин Борисов"

Как хорошему разработчику не стать плохим менеджером - Константин Борисов - Читать книги онлайн | Слушать аудиокниги онлайн | Электронная библиотека books-lib.com

Открой для себя врата в удивительный мир Читать книги / Домашняя книг на сайте books-lib.com! Здесь, в самой лучшей библиотеке мира, ты найдешь сокровища слова и истории, которые творят чудеса. Возьми свой любимый гаджет (Смартфоны, Планшеты, Ноутбуки, Компьютеры, Электронные книги (e-book readers), Другие поддерживаемые устройства) и погрузись в магию чтения книги 'Как хорошему разработчику не стать плохим менеджером - Константин Борисов' автора Константин Борисов прямо сейчас – дарим тебе возможность читать онлайн бесплатно и неограниченно!

220 0 12:01, 24-06-2021
Автор:Константин Борисов Жанр:Читать книги / Домашняя Год публикации:2020 Поделиться: Возрастные ограничения:(18+) Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних просмотр данного контента СТРОГО ЗАПРЕЩЕН! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту для удаления материала.
0 0

Аннотация к книге "Как хорошему разработчику не стать плохим менеджером - Константин Борисов", которую можно читать онлайн бесплатно без регистрации

В этой книге автор, сам прошедший путь от разработчика до менеджера в сфере IT, рассказывает неочевидные моменты, которые являются критически важными для правильного управления. Почему разработчики увольняются после повышения зарплаты? Как делать FixedPrice проекты? Почему Scrum не упрощает менеджмент? Книга содержит ответ на эти и многие другие вопросы. В книге есть много баек, которые показывают тяжёлую, но интересную жизнь менеджера в разработке. Иллюстратор обложки: Ксения Ерощенко. Иллюстрации в тексте книги авторские.
1 ... 23 24 25 26 27 28 29 30 31 32
Перейти на страницу:

Алексей ушёл думать. Он решил докопаться до сути и погрузился в исследование решения Игоря. Почему оно проще и быстрее? Вскоре Алексей выяснил, что менеджер вместо работы с базой использовал заранее приготовленные файлики JSON с нужными данными и показывал только первые 1000 записей. Поэтому и производительность была нормальной. Когда эти хаки убрали, решение менеджера стало тормозить так же.

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

На этом история не закончилась. После этого менеджер оспаривал любую оценку Алексея, заявляя, что всё должно быть проще и быстрее. Менеджер просил других разработчиков сказать свою оценку, чтобы проверить оценку Алексея. Иногда это были даже разработчики из других проектов. Все они, кстати, подтверждали оценки Алексея, но это не помогало.

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


Анализ

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

Самое интересный вопрос тут, это зачем менеджер полез в код? Он хотел ускорить работу разработчика? Зачем тогда он делал это втайне, и почему не взял ответственность на себя? Менеджер (а скорее тимлид) может перевести на себя какую-то задачу, если видит, что разработчик не сделает её. Но тогда нужно делать это полноценно, по процессу, доведя задачу до конца.

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

То есть вместо ускорения работы Алексея получилось значительное замедление. Причём, например, заставлять Алексея тратить время на убеждение команды и менеджера в правильности принятого решения было совсем излишне. В этом и суть распределения ответственности. Если разработчик принимает решение, то заставлять его аргументировать излишне. Это если решение должен принять менеджер, то ему нужны доказательства, информация и прочее.

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

Причём, здесь в высшей степени не важно, насколько хорошо Алексей сам подходил для решения задачи. Даже если действительно задача была простой “двухдневной”, а Алексей на неё тратил 2 недели из-за недостатка знаний. Ну и что? Менеджер может заменить разработчика или работать с тем, что есть. В конце концов, часто бывает, что тимлид работает с командой новичков. Там каждый(!) член его команды работает во много раз медленнее, чем он сам. Ну и что? Это нормально. Можно прокачивать свою команду, можно использовать их “как есть”. Но какой практический смысл в том, чтобы гнобить своих разработчиков? Это крайне непрофессионально.

Аналогичная картина видна и в продолжении истории. Какой смысл показывать недоверие всем оценкам? Зачем просить других членов команды подтверждать (или даже опровергать) оценки. Даже если есть какой-то Пётр, который может сделать какую-то задачу в два раза быстрее Алексея, то что из этого следует? “Я угадаю эту мелодию с трёх нот. – Угадывай!”

Смысл оценки в том, чтобы разработчик подписался на то, что он сделает задачу в срок. А то, что какой-то другой разработчик может сделать её в два-три-десять раз быстрее… Кому какая разница? Менеджер показывал своё недоверие Алексею, а значит и команде разработки в целом. Причём, команда подтверждала оценку Алексея, а менеджер выглядел совсем бледно.

Что делать в такой ситуации менеджеру? Прекратить показывать свои комплексы и неуверенность и начать управлять. Либо заменить разработчика, либо начать ему доверять, а не устраивать детский сад.

Что делать в такой ситуации Алексею? Я бы занял жёсткую позицию. Менеджер даёт свою реализацию задачи. Что он хочет, чтобы я с ней сделал? Изучил код? Это reverse engineering и пусть менеджер даёт согласие на эту трату времени. Либо пусть сидит и объясняет, как его код работает. Нужно принять решение по выбору кода, который идёт в прод? Отлично, решение принято, в прод идёт мой код. А, так нельзя, нужно сравнить решения? Тогда это исследовательская задача и пусть менеджер явно назначает такое задание, и принимает решение сам по результатам сравнения. При этом где-нибудь я бы эскалировал проблему менеджеру менеджера, так как явно он мешает работать.

А вот финал истории вполне закономерен. Менеджер потерял разработчика, причём не по своей инициативе. То есть и здесь у него всё пошло наперекосяк.


Как хорошему разработчику не стать плохим менеджером
История про деньги заказчика

Услышал интересные рассуждения от опытного фрилансера:

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


Как хорошему разработчику не стать плохим менеджером

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

Возможно, вам хочется написать мне какую-то историю из вашей жизни. Или, может быть, вы хотите мне написать, с чем вы не согласны. Или вам хочется, чтобы в следующей книге я написал о чём-то важном. Пожалуйста, напишите мне об этом на мою почту borisovke@gmail.com, мне будет приятно.

До новых встреч!

1 ... 23 24 25 26 27 28 29 30 31 32
Перейти на страницу:
Отзывы - 0

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


Новые отзывы

  1. Гость Елена Гость Елена12 июнь 19:12 Потрясающий роман , очень интересно. Обожаю Анну Джейн спасибо 💗 Поклонник - Анна Джейн
  2. Гость Гость24 май 20:12 Супер! Читайте, не пожалеете Правила нежных предательств - Инга Максимовская
  3. Гость Наталья Гость Наталья21 май 03:36 Талантливо и интересно написано. И сюжет не банальный, и слог отличный. А самое главное -любовная линия без слащавости и тошнотного романтизма. Вторая попытка леди Тейл 2 - Мстислава Черная
  4. Гость Владимир Гость Владимир23 март 20:08 Динамичный и захватывающий военный роман, который мастерски сочетает драматизм событий и напряжённые боевые сцены, погружая в атмосферу героизма и мужества. Боевой сплав - Сергей Иванович Зверев
Все комметарии: