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

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

Что необходимо знать

Я новичок в менеджменте проектов и мне необходимо сформировать кросс-функциональную команду. С чего мне начать и как найти подходящих людей?

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

Привет, Хабр! Меня зовут Максим Лютцау, в Промсвязьбанке я работаю product owner’ом. Почти год разработка нового интернет-банка «Мой бизнес» у нас идет по фреймворку Scrum, и в связи с этим я уже успел набить шишек. В этом посте я хотел бы рассказать о самых болезненных из них, а также о том, какие средства нам в итоге помогли. Чтобы вы смогли избежать подобных неприятностей.

Мир IT сегодня не похож ни на одну из других отраслей — над кодом приложений, игр, корпоративных решений, сервисов работают увлечённые, грамотные ребята. Программисты и инженеры, дизайнеры и тестировщики, системные администраторы и новомодные DevOps превращают идеи в программное обеспечение, которым пользуются миллионы людей. Они вдохновенно пишут код, разрабатывают алгоритмы, готовят макеты и соединяют это в работоспособные полезные механизмы. Мы, пользователи Хабра, часто говорим о разработке, администрировании, новых технологиях и языках программирования, зарубаемся в жарких спорах о преимуществах одного стека над другим, но забываем о важном звене в любой IT-компании — менеджерах проектов и продуктов. А между тем не факт, что завтра именно вам не предложат отойти от дел программерских и стать менеджером. Мотивация? Стоит ли? Потолок? Карьерный тупик? Новый горизонт? Давайте разбираться.

За свои 12 лет работы в сфере разработки ПО, мне посчастливилось поработать в команде только два раза. Хотя я сменил порядка десяти мест работы. Но попробовав раз, ем и сейчас… Т.к. я не жадный, и готов своими достижениями делиться с сообществом, то решил я предпринять попытку вывести из равновесия неумных руководителей, которые до сих пор не осознали важность команды, а также тех руководителей, которые профессионально занимаются самообманом — мол, они строят команду, а на деле — тьфу, а не команда.

Однажды я управлял разработкой проекта и столкнулся со странной ситуацией: с каждым днём я делал всё больше, но дел только прибавлялось. Чем больше я задерживался на работе, тем больше я не успевал. В итоге, когда туман рассеялся, я обнаружил, что я занимаюсь совсем разными делами, в которых я не имел должной компетенции: переводы, аналитика, техническое писательство, тестирование, разработка, причем на разных платформах, поиск кадров, найм и непосредственно управление разработкой. Ситуация, мягко сказать, плачевная. Надо упомянуть, что это был первый проект, которым я управлял и, наверняка, опытным управленцам мои ошибки покажутся идиотскими, а выводы наивными. Но, в любом случае, для систематизации опыта я провел ретроспективу и хочу протестировать ее выводы с помощью сообщества.

Далее привожу все найденные мной факторы, которые привели меня к столь неприятному положению дел.

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

Автор: Евгений Ефимов
QA Lead, DataArt

Моряки, самолеты и корпорации

• Н.Н. Талеб и моряки.
• Абрахам Вальд и самолеты.
• Левитт и корпорации.

Существует понятие «систематическая ошибка выжившего». Оно встречается в книгах Талеба “The Black Swan. The Impact of the Highly Improbable” («Черный лебедь. Под знаком непредсказуемости» и “Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets” («Одураченные случайностью. Скрытая роль Шанса на рынках и в Жизни»). Он описывает красивую картину, на ней древнегреческие моряки молятся богам во время шторма. Богам нравится, как они молятся? и поэтому моряки спасены. Шторм превращается в штиль или слабый ветер, корабль доплывает до берега, и все остаются целы. Когда спрашивают других моряков, как удалось доплыть, они тоже говорят: «Мы молимся богам и всегда доплываем». Проблема в том, что мы не можем спросить об этом моряков, которые утонули. Возможно, что они тоже молились, но не доплыли. И вообще дело было не в этом, а, т. к. в то время почти все моряки были религиозны, можно предположить, что молились все. И есть вероятность, что это не действует.
Вторая история — про математика и статистика Абрахама Вальда и про самолеты. Действие происходит во время Второй мировой войны. Британские бомбардировщики возвращаются на базу. Задача — понять, где и как укреплять самолеты, чтобы как можно больше возвращалось и как можно меньше падало. Они смотрят на самолеты, которые вернулись, и говорят, что необходимо укреплять наиболее поврежденные попаданиями части. Поскольку в них все время стреляют, мы их укрепим, и все пули улетят обратно во вражеский самолет и всех там перебьют.

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

Стивен Левитт написал интересную книгу «Фрикономика». Он выбрал стандартные книги из серии «10 шагов к успеху» и проанализировал две книги, где рассказывалось про корпорации, использовавшие нововведения, которые привели их к успеху. Эти книги были условно написаны в 2000 году, и корпорации, используя эти наработки, побеждали остальные компании. На момент, когда Левит их анализировал оказалось, что три четверти этих корпораций закрылись. Они оказались убыточными, потому что внешняя среда поменялась, а они не изменили подход к успеху. Соответственно, все эти истории успеха не всегда и не для всех работают.

Есть такое понятие, как «систематическая ошибка выжившего», когда мы собираем статистику там, где ее проще найти. От тех, у кого все получилось, от тех, кто выжил, и учитываем только ее. А статистику о тех, у кого что-то не получилось, мы не учитываем. Все эти факторы могут сильно искажать нашу действительность и повлиять на то, как мы будем принимать решение. Иногда гораздо более интересная информация есть у тех, кто не выжил.

Хабраприветствую всех, кому интересна эта тема.

Конечно же, микроменеджмент встречается не только в IT, но именно в этой сфере указанный черный ритуал может принести значительный вред процессу разработки и конечному результату, не говоря уже о профессиональном развитии сотрудников.

После публикации статьи «Лень как признак гениальности. 4 вида лени и нужно ли с ней бороться» на Мегамозге появилось несколько очень интересных, но местами противоречивых статей про прокрастинацию. Я тоже хотел было написать статью про прокрастинацию, но, чтобы окончательно не разрушить мозг нашему дорогому читателю решил вместо этого обобщить материалы и копнуть немного глубже, дать некоторую аналитику, откуда же берётся лень, прокрастинация и перфекционизм (новинка!), а также может ли одно переходить в другое. Те, кто не читал предыдущие статьи, смогут в этой статье получить полное представление о данных проблемах, чтобы быть в тренде. Надеюсь эта статья станет хорошим завершением «недели прокрастинации на Мегамозге» и будет максимально полезной в решении этих нелегких задач.

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

1. Нужен ли вообще тимлид?
2. Что есть тимлид, какие у него задачи?
3. Что сначала: команда или тимлид?
4. Необходимы ли тимлиду технический навыки?
5. Вырастить или нанять?
6. Как понять, можно ли и нужно ли выращивать из инженера тимлида?
7. Сколько времени нужно, чтобы вырастить тимлида?
8. Менеджерские роли тимлида, какая роль предпочтительней?
9. Насколько важны эмоциональный интеллект и социальные навыки?
10. Что делать если руководитель сам является техническим специалистом и падок на микроменеджмент?
11. Тимлид ушел на неопределенное время (отпуск, больничный, форс-мажор), что делать?
12. Что делать, если тимлид уходит насовсем?
13. Какое должно быть соотношение менеджмента и разработки в работе тимлида?
14. Есть ли путь назад (и вперед)?
15. Какие перспективы карьеры тимлида?
16. Что может помешать стать тимлидом?
17. В чем разница между тимлидом и техлидом?
18. Как выявить неэффективного тимлида на ранней стадии?
19. Как начинающему тимлиду справиться с потоком информации?
20. Нужен формальный или неформальный лидер?
21. Junior и Senior тимлид, в чем различия и как держать их в одной команде?

Такой поток запросов выдали участники TeamLead Conf на круглый стол. Если вы уже сталкивались с какими-то из них, то, вероятно, и остальные могут вас настигнуть, есть, о чем подумать.

Под катом — обзор лучших докладов TeamLead Conf с видеозаписями и презентациями.

В феврале этого года мы провели первую конференцию для тимлидов и о тимлидах. Конференцию посетило более 500 человек. Главным итогом можно считать то, что в принципе сообщество признало наличие проблемы, о чем свидетельствует количество и состав вопросов, которые были подняты на круглом столе (мы писали об этом в  обзоре). Поскольку есть проблема, то нужно искать её решение, что мы и планируем сделать в рамках Saint TeamLead Conf в Санкт-Петербурге 24 и 25 сентября. Прием заявок на доклады ещё идёт, и о конкретной программе говорить пока рано. Давайте поговорим о целях Программного комитета, вспомним прошедшую конференцию, а также поговорим о том, что ждёт нас в конце сентября в Питере.

На пути от традиционной иерархии developer – teamlead – CTO до загадочного Servant Leadership в booking.com проходили и автономию. Отличная идея, дать людям свободу, возможность развиваться, расти, самим достигать цели, должна была замотивировать сотрудников.

Георгий Могелашвили (glamcoder) на TeamLead Conf рассказал обо всех этапах, и в том числе о том, что нельзя просто так объявить автономию, а тимлидов отправить на мороз. Компания тестировала организационные изменения, проводила тренинги, и автономные команды таки сработали. Но только вовлеченность людей не выросла, а местами даже упала. Тогда процесс реорганизации начался с новой силой и тимлид вернулся, но уже с другой ролью.

Под катом подробности и современное устройство менеджмента в компании с 1500 сотрудников в IT.


О спикере: Георгий Могелашвили больше 10 лет в IT, последние четыре года работает в Booking.com в Амстердаме, 2 из них — тимлид.

Затронем три основные темы:

• Процесс эволюции (через что мы прошли за то время, пока я был в компании).
• Автономность — хорошо это или плохо, и почему у нас это было.
• Концепция Servant Leadership.

Предисловие

«У нас приемлемый уровень брака!» именно с этой фразы начинается общение почти с каждым директором по качеству на производственных предприятиях в России. Многие из них даже будут уверять, что добились качества мирового уровня в виде 3,4 бракованных изделий на 1 000 000 произведенных. Да и в целом на всех профильных форумах и конференциях мы слышим, что в России лучшее качество в мире, а все остальные страны нам завидуют.

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

Во времена СССР качество достигалось за счет полного и непрекословного соблюдения всевозможных ГОСТов. Но, к сожалению, в наших реалиях соблюдение ГОСТов не является приоритетным требованием (за исключением предприятий ВПК), а главная цель производства — сделать все быстрее и дешевле. Исходя из этого тезиса у нас активно внедряются методы оптимизации в виде инструментов Lean и сокращается персонал при увеличении объемов производства.

Современное развитие IT технологий позволило обуздать громадные потоки данных.
У бизнеса появились различные инструменты: CRM, ERP, BPM, бухгалтерские системы или в крайнем случае просто Excel и Word.

Компании тоже бывают разные. Некоторые, состоят из множества обособленных филиалов. В таком случае у бизнеса возникает проблема синхронизации данных в зоопарке IT систем. Тем более, что у филиалов отличаются вендоры или версии ПО. А частые изменения требований к отчётности от управляющей компании вызывают приступы неконтролируемой “радости” на местах.

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

Иной раз чудится, что тимлид — это кто-то или что-то вроде Снарка из поэмы Льюиса Кэрролла: точно существует, разносторонне и противоречиво описан в своих бытовых и деловых проявлениях, но при всем при том что представляет собой — загадка. Разобраться с тем, насколько значима эта (тимлида, не Снарка) роль в инженерных командах, кого правильнее на нее ставить и какие подводные камни скрыты в «тимлидстве», обещает помочь Saint TeamLead Conf 2018, которая пройдет 24–25 сентября в Санкт-Петербурге.

За месяц до мероприятия мы без лишних формальностей поговорили с техническим директором проекта Mos.ru Романом Ивлиевым, который возглавляет Программный комитет Saint TeamLead Conf 2018. В беседе: кто такие тимлиды, как их правильно готовить, кого и к чему должны готовить они, каким должен быть круг их обязанностей и многое другое.