Рубрика «управление разработкой» - 4

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

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

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

У меня получилось четыре категории:

Читать полностью »

image
Прошло больше полугода с момента выхода фреймворка для C++ 🐙 userver в open-source. За это время мы многое узнали, на многом настрадались, а главное — получили много приятных сюрпризов.

И мы решили об этом написать. Рассказ будет полезен тем, кто ведёт или планирует вести свой open-source проект или занимается контрибьютами. Остальным будет интересно почитать про чужое набивание шишек и что вообще open-source даёт проекту.
Читать полностью »

Не волнуйтесь за них, мы позаботились об их бэкапе

Не волнуйтесь за них, мы позаботились об их бэкапе

Когда-нибудь в твоей стране запретят IaC и ты вспомнишь про мои бэкапы…
© Джейсон Стетхем

Не так давно мы в компании столкнулись с маленькой проблемкой - RabbitMQ Читать полностью »

Почему увольняют самых опытных? Потому что они слишком умные. Тейлоризм 21-го века - 1

Опытный и талантливый сотрудник — носитель знаний и опыта. На него полагаются коллеги, он выполняет в десять раз больше работы, чем джун. Казалось бы, руководство должно молиться на такого разработчика. Но нет, к нему не испытывают особой благодарности и зачастую рады от него избавиться. Почему так происходит?Читать полностью »

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

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

Два типа разработчиков ПО - 1

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

Согласно моей теории, есть два типа разработчиков ПО:

Когда тип 1 узнаёт о задаче, он думает: «Это легко, люди просто могут делать X».

Когда о той же задаче узнаёт тип 2, он думает: «Это очень сложно, ведь для этого нужно, чтобы люди делали X».

Тип 1 предполагает, что задача проста, если она не техническая, потому что «можно просто попросить людей делать X». Тип 2 считает, что она сложна, потому что она не техническая.
Читать полностью »

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

Читать полностью »

Отстаньте от разработчиков: не надо делать их руководителями просто ради грейда - 1

Бич профессии — превращать самого опытного разработчика в плохого менеджера. Я видел ситуации, когда синьор перерастает команду и ему предлагают должность руководителя. Многие соглашались и становились несчастными. И ладно бы только они: страдает-то в итоге команда и компания.

Зачем они соглашаются? Во-первых, потому что они росли всегда и останавливаться страшно. Во-вторых — это часто единственная возможность повышения.

Что мы поменяли у себя в разработке Газпромбанка:

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

Куда можно расти? В хеда профессии — эксперта, к которому может обратиться каждый в компании. Это как Стив Возняк в Apple.

Как это ни странно, в развитой инженерной культуре такие «эксперты выше синьора» — норма. В России я встречал мало компаний с такими фичами, поэтому хочу поделиться практическим опытом того, что это даёт.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js