ItBrunch: "Учимся на чужих ошибках", 9 июня 2012

В прошлую субботу докладывал на очередном ItBrunch. Для начала хотел бы еще раз сказать что очень полюбил этот формат по прошлым конференциям.

Доклад Тимофея, как всегда, был очень живой и жизненный. Несколько раз в уме всплывало "у нас тоже так было :(". Богатый опыт консультанта позволяет Тимофею раскладывать негативные ситуации на проектах в набор стандартных проблем с возможными путями для их преодоления.

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

Доклад Бориса Вольфсона развил тему "классического аутсорсинга" и его ошибок. Набор очень удачных антипаттернов по ведению проектов заставил меня не раз улыбнуться.

Доклад Виктора Малого (если переврал фамилию в родительном падеже  - прошу прощения) также обратился к  ежедневным реалиям "классического аутсорсинга" в разрезе тестирования. Временами не могу сдержать улыбку вспониная истории из жизни.

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

Николай затронул очень интересную тему - анализа процесса разработки. Особенно это актуально для распреденных команд. Да что рассказывать - лучше смотреть и/или слушать.

Ну и немного про мой доклад. Во-первых, сказалось волнение - все такие первая онлайн конференция. Выступать не видя аудитории немного нОво и по своему труднее. Так что я забыл включить запись звука, из-за чего не могу похвастаться слайдкастом. Так что представляю на суд аудитории слайды.

!Сделай сам

View more PowerPoint from Oleksiy Rezchykov

После доклад получил ряд очень интересных вопросов, ответы на которые и хотел опубликовать.

Andrey

Q: и все же, всегда есть "неинтересные" задачи... как правильно их распределить, чтобы никаого не обидеть и не тянуть этот груз самостоятельно?

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

Екатерина

Q: Как можно вмешаться в постоянный конфликт членов команды, чтобы не быть принятым в штыки? Как помочь людям начать переносить друга друга?)

Anastasy

Q: как все-таки бороться с личностными конфликтами?




Если конфликт профессиональный это может быть либо обычный холивар либо реальное несовпадение взглядов на инженерные вопросы. Холивары стоит прекращать как пустую болтовню, если же он сильно мешает работе можно заставить основных действующих лиц защищать сторону оппонента. Такой ход может немного остудить стороны. Если имеет место различие взглядов на решение задачи или другая объективная причина инжеренного хакартера - ее можно вынести на общее обсуждение с созданием списков за и против и последующим голосованием либо принятием единоличного решения ТЛ.

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

Вера

Q: как уладить конфликт между тим лмдом и командой? что делать, когда личность тим лмда неприятно команде и стоит стеной на пути к нахождению компромиса?

Если у команды проблема с ТЛ, тогда необходимо искать арбитраж. Обращаться к ПМ

Вера

Q:  вопрос собственно такой -  не как уюрать или наказать тим лида, а как сплотить команду?

Ответ тут не может быть простым. Команда должна сплотиться либо вокруг идеи, либо вокруг человека. Если этот человек не ТЛ им должен стать кто-то другой. Идеей же может послужить достижение высокой продуктивности команды, например.

Вера

Q: а просьба убрать тим лида не породить практику "он нам не нравится - убираем!"? :))

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

Ihor

Q: з чього почати приміряти комнди

Спасибо Игорю за вопрос, начинать, на мой взгляд стоит с ретроспективы - собрания на которм всем дать возможность высказаться по поводу текущей обстановки в команде. Собрать список проблем, выделить основные из них (лучше голосованием). Далее попробовать понять (для этого хорошо подходит методика "5 почему" или любая другая позволяюшая добраться до истинной причины). После чего составить и согласовать список действий.

Vasyl

Q: стоит ли наказивать рутинными задачами ленивых или провенившихся разработчиков буть от синьйором или джуниором ?

Ленивых стоит выгонять! Если они не исправятся после предупреждения. Если конечно речь идет о лени а не о прагматизме :) Стоит разобраться в причинах того, что Вы считаете ленью. Если кто-то не поддерживает идей команды и не делает все что от него зависит для победы, то возможно, такой человек не нужен команде. Если же по какой-то причине человек переносит спад производительности - стоит пойти ему на встречу. Если же речь идет о банальном "воспитании характера" у разработчика - то тут решать ТЛ, он должен понимать насколько человек "воспитуем".

Dmitriy

Q: как правильно оценивать сроки выполнения задачи? когда ПМ даёт ТЗ и спрашивает, сколько времени это займёт.

Реалистично. Не стоит "завышать" или "занижать" сроки. А вообще Scrum дает неплохой ответ на этот вопрос.




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

Материалы появятся на сайте конференции в ближайшее время. Часть уже есть в твиттере по хештегу конференции #itbrunch.

Закончить же хотел словами благодарности организаторам и докладчикам. Как уже писал на твитере - немного разбавили летний конференционный вакуум.