История первая: Не верю
Произошла у меня в пятницу интересная ситуация. Готовлюсь к отъезду на тренинг в Москву. Осталось 4 часа до поезда, и тут звонит девушка, отвечающая за печать методичек: “Принтер поломался, альтернативный принтер стоит вдвое дороже и впятеро медленнее. Он не успеет до отъезда. Что делать будем?” Ладно, начинаем думать и искать альтернативы. А пока договариваемся созвониться чуть позже. Задумываюсь… И тут ловлю себя на том, что вместо бурного гугления и вспоминания ближайших копицентров – тупо читаю гуглридер :( Ну вот не хотелось заниматься этой проблемой, хотелось о ней просто забыть. Ситуация, впрочем, успешно разрешилась – Марина нашла третий вариант.
История вторая: Ребенок
На одном из проектов синьор-девелоперу Петру пришло невнятное задание от заказчика. Он задал вопрос, и стал ждать ответа. Поскольку ждать было скучно, он врубил WorldOfWarcraft. На второй день ответа не было все равно, хотя пришло письмо от заказчика на околопохожую тему. Петр очень громко и эмоционально поворчал и сел играть дальше. PM в этот момент был далеко и слабо контролировал процесс. PMа можно даже понять – идти на конфликт с Петром, выясняя как дела, ну ооочень не хотелось. Тем более, было много других дел, а синьор на то и синьор, чтобы не нуждаться в микроменджменте.
Через неделю ответа так и не было. Петру спрашивать уже было страшно – ведь первый вопрос от заказчика будет “а что ты сделал за эту неделю?”. И он продолжал тихо играть и громко ворчать в кампании мидлов и джуниоров.
Через две недели заказчик стал интересоваться, когда фича будет завершена. Теперь уже Петр игнорировал почту и выключил скайп.
В конце концов заказчик позвонил коллеге и спросил “А в офисе ли Петр? Можно ли его к телефону?” Петр громко отказался, “не хочу с козлами разговаривать” – и убежал из комнаты.
Итог: Петр уволен с треском на следующий день. Говорят, сильно поменялся после полугода безработицы на шее у жены. Через месяц “по совокупности обстоятельств” заказчик ушел от нас.
История третья: Власть манит
На проекте были неформальный лидер Тамара, умнейший senior-QA, и непрерывно сменяющиеся PMы и техлиды. Почему они часто сменялись? Потому, что команда шла за неформальным лидером. Они знали ее давно, и ей и подчинялись. Ее парень работал тут же, а два слаженных человека любую неорганизованную команду построят. Новички на проекте должны были либо принять ее главенство, либо пойти на прямой конфликт.
В этой ситуации формальные лидеры не могли сделать ничего. Вспоминая этот проект, один грамотный PM сказал “я месяц спать не мог, тупо не знал что делать”.
А делать было надо – Тамара боролась за власть и с заказчиком тоже. Как это выглядело? Она часами загоняла его в тупик коварными вопросами “с подковырками”, потом ловила на логическом противоречии и результат выкладывала во внутрикомандный чат “посмотрите, какой дурак”. Команда, естественно, ее поддерживала.
Итог: от проекта отказались. Формальная причина – внешний рейт стал слишком близок ко внутреннему.
Что общего в этих историях?
Мы привыкли считать, что кругом нас люди поступают логично. Что в IT работают умные люди с ясной головой и железными нервами.
К сожалению, это не всегда так. Кто-то не умеет сохранять спокойствие под давлением, а кто-то – хочет много внимания…
У каждого есть свои минуты слабости и свои слабые стороны.
Что тут важно? Для менеджера тут важно:
- вовремя заметить
- быстро и правильно диагностировать
- вовремя и грамотно вмешаться
А вот как и что тут можно сделать мы поговорим в следующий раз :)
Истории заинтриговали.
На самом деле, по моему в первой ситуации ты поступил правильно. Во-первых, был человек, который ответственен за это, и он по идее более информирован в альтернативах — что, где, почем. У тебя было всего два решения, которые можно было принять: либо брошюры не очень важны, и тогда ничего не надо менять, либо они очень важны, и тогда ты бы бросился переносить поездку. Поскольку ты этого не сделал, очевидно, что ехать можно было и без них, поэтому — зачем тратить зря нервы на панику?
Во втором случае — неправильное распределение обязанностей. Никакому девелеперу, ни сениору, ни джуниору, никаких писем от заказчика приходить не должно. Они должны приходить ПМу. И именно он должен долбить заказчика до получения вменяемого ответа, что бы девелоперы могли работать. Заставлять девелопера любого уровня общаться с заказчиком — верный путь завалить проект.
В третьем случае — формальный лидер мог и должен был уволить Тамару сразу. Даже если бы следом ушло пол-команды. Пусть работают пять человек, чем не работают десять.
Олег, брошюры мне были нужны гораздо больше, чем Марине. Тут не нервы нужно было тратить, а время.
Вторая история – в каждой фирме есть своя политика и своя методика. Скрам вообще считает, что роль PM лишняя :)
С третьей – полностью согласен. Запустили ситуацию.
По поводу второго — никогда нельзя забывать, что мы работаем не с политиками и методиками, а с людьми. И найти одного отвественного ПМа, который умеет общаться и с клиентами и с девелоперами, гораздо легче да и банально дешевле, чем искать десяток сознательных девелоперов, которые умеют и любят общаться с людьми. Человек должен заниматся той работой, которая у него получается, и главное — которая ему нравится, и никакой скрам не заставит его общаться с заказчиком, если он это не любит и не умеет.
Уведомление: Где же логика? | Психология в IT