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

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

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

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

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

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

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

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

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

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

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

(с) оригинал


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

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

Комментарии

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

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

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

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.