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

Первый на русском или хороший повод

Давно собирался начать вести русский блог. Может с ним получится лучше, чем с подмороженным на английском. Тем более повод имеется просто отличный.

Сегодня состоялась первая конференция Software Project Management. Организована она была компанией SQALab, у которой получилось собрать в одно время и в одном месте много умных людей с интересными идеями про то, как правильно управлять проектами в IT, как работать с командой, какие процессы и как использовать. Большое спасибо SQALab за возможность это все послушать и пообщаться с коллегами.
Итак о моих впечатлениях в целом и о тех докладах, которые удалось посетить.

Сначала о докладах.
Макс Вишнивецкий (@vishmaks). "Отдельные вопросы анатомии менеджера".
Несмотря на медицинское название разговор шел об ошибках, которые часто совершают молодые (я думаю не только молодые) менеджеры: недостаток опыта часто компенсируется (или усугубляется) горячностью, увлечением новыми технологиями и практиками. При этом только с опытом понимаешь, что знаменитые проектный треугольник PMI (бюджет, сроки, объем работ) на самом деле выглядит далеко не как треугольник, а скорее как многогранник. Макс предложил свой вариант треугольника, который, на его взгляд, отражает, как правильно работать с командой. Его составляют доверие, воспитание команды и умение ее защищать. Рассказывалось все очень увлеченно и зажигательно и сопровождалось замечательно подобранными слайдами. Я думаю, что все проснулись (доклад был первым) и получили заряд на весь день. На вопрос "нужно ли помогать менеджеру избегать ошибок" Макс ответил, что "грабли" очень полезны, более того иногда имеет смысл предлагать ему неверную подсказку на его вопросы (для получения иммунитета видимо :)

Лиля Горбачик (@Gorbachik_Lilia) "Как сохранить команду в эпоху перемен"
Доклад в целом неплохой, но без фейерверка. Рассматривались проблемы, с которыми сталкивается менеджер, когда в компании грядут перемены. Для общего развития имеет смысл посмотреть/послушать, но меня не зацепило. Из запомнившегося - "всегда надо готовится к разговору с сотрудником". Ну и уж очень часто звучала пропаганда курения, как способ успокаиваться :), хотя сама она я так понял не курит. Пообщался в кулуарах, по поводу вопросов тестирования (Лиля из QA) и взаимодействия команд разработчиков и тестеров. Она озвучила мысли совпадающие с моими, а именно что эти команды не могут быть по разные стороны баррикад - цель одна: продукт.

Вика Придатко (@nikavika) "Техническое интервью с человеческим лицом"
Вика была в ударе :) Как в общем и обычно на ее докладах. Раньше смотрел в записях - вживую круче :)
Тезисы:
"Первое впечатление второй раз не создается" (классная мысль)
Общайтесь с кандидатом, как с членом вашей команды
Слушайте людей
Всегда задавайте вопрос "что вам важно?"
Берите людей, которые обожают то, что делают
Обязателен feedback, это важно для имиджа компании
забавные вопросы для собеседования:
"Какой самый интересный вопрос вам задавали на собеседовании?" (а вдруг потом вам пригодится :))
Что вам нравится в себе?
Последнее важно не путать с "Кем вы видите себя через 5 лет?" - это булшит

Михаил Завилейский (Ген. менеджер DataArt SPb) "6 хороших идей, которые я бы не посоветовал реализовывать, пока это возможно"
Зачетный доклад, надо еще раз пересмотреть в записи
Тезисы:
- Соревнования между командами - часто больше вредит, чем помогает.
-Нужно ли доводить дело до конца? (лисы vs ежи). Лисы часто не могут доделать дело до конца, ежи всегда доделывают. Программеры почти все лисы. Интересный пример про гору с кучей трупиков ежей под ней. "Если то, что ты обещал нужно только тебе - то ты сам вправе решать нужно ли это доделывать или нет"
- Об измерениях (KPI): измерения могут изменить поведение измеряемой системы (и чуток квантовой физики для примера :) и не факт, что эти изменения будут полезны.
- Кнут vs пряник. На пряник обычно не хватает денег, так может и кнута не надо? Человек сам переживает, а если нет - то с таким расставаться. Нужно благодарить людей и делать это часто. Кстати тема благодарности команде звучала сегодня очень часто на разных докладах.

Сергей Архипенков (очень умный и суровый) "Антипаттерны командного поведения"
Какие бывают типы людей и как это нужно использовать. Пересказывать я бы не рискнул, надо просто посмотреть запись.
Из запавшего в мозг:
- Все программисты - меланхолики (интересно действительно так? Про себя бы не сказал, но я все же не до конца программист)
Надо поощрять командное поведение
"Твое ДА ничего не стоит, пока ты не говоришь НЕТ" - нужно любить людей, которые умеют отстаивать свою точку зрения.
"Ни в одном ВУЗе не учат РАБОТАТЬ"
3 признака хорошего менеджера
- приверженности проекту
- эмоциональный интеллект
- лидер умеющий видеть цели

Оля Павлова (@op) "Курс молодого бойца для менеджеров" или как жить без HR
Очень драйвовый, я бы сказал, жесткий доклад. Рекомендую.
тезисы
Искать людей надо до того, как они понадобятся
Не надо быть как все (на HH.ru работу никто не ищет, как и работников - хмм прикольно, я обычно там и делал и то, и другое)
Программисты - ауты (тут я вообще присел...)
Опять про важность обратной связи с соискателем (донести до него принятое в итоге решение)
Используешь микроменеджмент - убей себя об стену (блин, я грешил этим...)
Все это должно делаться честно и от сердца...

Асхат Уразбаев (scrumtek) "Развитие IT-организации"
Видимо я был оглушен докладом Оли, в итоге у Асхата я переваривал услышанное... Надо будет пересмотреть.

Евгения Фирсова (@diffidence) "Покажи мне свои папки"
Честно не ожидал от этого доклада такого потока полезной информации. Очень хороший докладчик и позитивная девушка в японском стиле :)
Был приведен свой набор антипаттернов, мешающих менеджеру
"Даймё" (япон.)
работа в стиле "все уже решено, согласовано и не может быть изменено". Как бороться: привлечение сторонних экспертов, "стравливание" самих даймё, обозначение рисков, если не удалось их победить.
"Рикша" - (сел к вам в коляску и свесил ножки) "вы начинайте делать, а я пока подумаю, зачем оно надо". "доступ к телу" строго по расписанию и по правилам
Как бороться: стараемся понять как он работает. И ходим, ходим, ходим - менеджер не должен сидеть.
"Чайный домик" (созерцание) - "постоянный негатив" как то я не уловил ассоциации...(Update: см. комментарий от Жени (aka Saigo) ниже, ну и слайды обязательно смотрим)
Как боремся: проговариваем проблемы вслух, всегда благодарим команду, делаем выводы на будущее...

Рома Юферев (http://a-jail.blogspot.com/) "Шарада для менеджера"
Рома отжег, мега-доклад в формате комикса (по-моему лучший доклад, из тех что я сегодня послушал). Под конец напомнило речь пастыря-евангелиста :)
Любимые отмазки менеджеров:
- А что я могу сделать?
- А что, можно было?
- А какова политика компании по этому вопросу?
Какие еще проблемы: паника, проект "сжирает".
Решение: у вас есть свобода выбора и ВОЛЯ.
"можешь свалить на Кубу, а можешь сделать свою Кубу прямо здесь" - Ты можешь изменить реальность. "Не сиди на попе ровно" :)

Иван Селиховкин (http://pmlead.ru/) "Руководитель проекта - жизнь до и после найма"
История про улей и то, как менеджер должен доказать что он пчела, а не медведь.
Важно показывать результат команды в цифрах.
Что и когда показывать:
Риски - всегда до старта проекта
данные из треугольника PMI, риски , документы - в течении всего проекта
Рекламации, снижение стоимости команды - в конце проекта
и обязательное сравнение всего этого от проекта к проекту.

Вот собственно и все, что удалось послушать и посмотреть. Было здорово пообщаться с теми, кого до этого только читал в блогах и твиттере. В конце конференции был розыгрыш ценных призов от спонсоров и организаторов. iPad2 я конечно не выиграл, но 100% скидка на любую следующую конференцию SQALab - МОЯ, за что SQALab большое спасибо.

Update: благодаря Стасу Фомину есть возможность посмотреть видео докладов

Комментарии

  1. Макс спасибо! Была очень рада увидеться лично :). Давай еще!

    ОтветитьУдалить
  2. Спасибо за отзыв!

    > "Чайный домик" (созерцание) - "постоянный негатив" как то я не уловил ассоциации...

    Идея была в том, что клиенту чайного домика все должны угождать, а он не собирается никого благодарить.

    ОтветитьУдалить
  3. 2Вика: ты даже не представляешь, как я рад :) Забыл написать, что хотелось бы поучаствовать с тобой в собеседовании, причем и как соискателя, так и собеседующего.

    2Saigo: да Женя, я потом пересмотрел еще раз слайды и врубился. Спасибо за доклад.

    ОтветитьУдалить
  4. Спасибо за отзыв и за вектор работы над собой. Было очень приятно пообщаться.

    ОтветитьУдалить

Отправить комментарий

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

Mock vs Stub

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

Заметки на коленке - 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

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

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