К основному контенту

Обзор-неконспект "Идеальная IT-компания. Как из гиков создать команду программистов"

По наводке Леши Пименова прочитал эту книжку.

Общее резюме (сразу в начале): книга ОБЯЗАТЕЛЬНА к прочтению менеджерами-новичками и теми, кто хочет ими стать.
Разработчикам-технарям тоже будет полезна (разработка - это командная работа) - надо выйти за рамки IDE и посмотреть на свою работу с другой стороны.

Те менеджеры, которые отработали уже от ~5 лет и выше, скорее всего, набили все шишки и к решениям из книги пришли самостоятельно. Они им или уже следуют, или идут своим "уникальным" путем.
Таким эта книжка покажется "попсовой": одни, правильные, менеджеры найдут там мало нового, другие, эээ "уникальные", менеджеры советам скорее всего не внемлют.

Мои заметки на полях (возможно сумбурно).

Разработка - командная работа. 
Строится на 3-х китах: Скромность, Уважение, Доверие.
Работа в команде без общения - нонсенс. Надо уметь правильно коммуницировать. Сихнронные vs Асинхронные коммуникации.

Про лидерство в команде
Вредные советы - чего делать категорически не нужно
Отрицательная обратная связь в виде "конфеты" (снаружи про положительное, потом (внутри) про отрицательное и снова про положительное) - по мнению авторов вредна. В книге используется модель сендвича, а не "конфеты", но сути не меняет. Вообще, я думаю, разговор не о пользе или вреде, а об умении пользоваться этим способом выражения своего мнения. И тут хорошо идет тема честности в книге.
Хороший вопрос для встреч "1:1" - "Есть что-нибудь, чего тебе не хватает?"

Про мотивацию
Описывается модель Пинка ("Драйв" - ждите моего отзыва, а пока вот обзор Леши и видео)

Как повысить внутреннюю мотивацию:
  • независимость
  • мастерство
  • цель
"Вредоносный" участник - кто, что и как с ними работать.
Тут просто цитата 
"Следует отфильтровывать именно поведение, а не отдельных личностей. Наивно думать, что человек на 100% хорош или плох; гораздо конструктивнее и практичнее обнаруживать недопустимое поведение и пресекать его."
И много полезных практических советов по конкретным ситуациям возникающих внутри команды или на уровне компании.

Про позиционирование команды в компании (искусство корпоративной манипуляции)
Тут замечены новые термины: "наступательная" и "оборонительная" работа команды.
"Наступательная" - работа по производству нового функционала
"Оборонительная" - работа по возврату технического долга и вспомогательные вещи.
Отличные метафоры - буду использовать.
Рекомендуемое соотношение: 1/3 от всего времени можно отводить на "оборону". Если больше - польза приносимая командой будет неочевидна.
Вспомнился этот твит:

(с) оригинал


Письмо начальнику: правило "3 пункта и призыв к действию". Отлично.

Ну и про отношение к пользователям вашего продукта. 
Не забывать про них! Важны эмоции. Паттерн "первая минута пользования"

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu