Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать.
Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
Здравствуйте, Ed.ward, Вы писали:
EW>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
01.04.2011 14:38, michael_isu пишет:
> > Ок, человек столкнулся с проблемой, которую не удается решить. Что > делать дальше?
Ваши действия дальнейшие зависят от того, что вам надо.
Гмм. А твоя-то роль в этой петрушке — какая? Если ты такой же рядовой разработчик или вообще сторонний наблюдатель, то — продолжай наблюдать, чем кончится, пусть проблему решают те, кому за это деньги платят. А вот если ты менеджер проекта — ты обязан вмешаться, если есть риск срыва сроков, это твоя служебная обязанность, за это ты деньги получаешь.
1. Откуда вообще взята магическая цифра "160 часов"? Это оптимистиная, пессимистичная или средняя оценка? Как она получена — почему не ровно 100 или 200? Риски при планировании рассматривались? Есть у тебя план управления рисками? Какие действия предусмотрены для риска "Риск срыва сроков"? Как он идентифицируется?
2. Почему "объяснения этого не пустые, но достаточно размытые"? Ты не можешь оценить реальное состояние дел? Привлеки специалиста более высокого уровня (эксперта), чтобы он оценил масштаб катастрофы, предложил способы преодоления проблемы и оценил сроки. Спецификация на модуль есть? Насколько подробная? Описывает ли она (и предусматривает ли вообще) те проблемы, с которыми столкнулся разработчик?
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, Ed.ward, Вы писали:
EW>>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
_>Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
Помочь её решить. Научить решать подобные задачи самостоятельно.
А главное научить сообщать о затыках в работе самому. Но это зависит от менеджмента. Если за неспособность решить проблему наказывают, разработчик будет скрывать и тянуть сроки.
Здравствуйте, michael_isu, Вы писали:
EW>>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений. _>Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
помочь ее решить.
это можно сделать самому, если есть соответствующий опыт.
или при помощи стороннего специалиста (другого сотрудника имеющего опыт или внешнего специалиста).
а это разве не очевидно?
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи.
Из этого следует, что причины есть, они действенные, но почему-то не озвучиваются. Исходя из априорной добросовестности получаем, что человек не может чего-то понять — вот он и "тормозит", поскольку размышления требуют времени.
_>Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Тактично и вежливо вмешаться в процесс решения. Часто бывает так, что специалисту для принятия окончательного решения не хватает какой-то информации, но он сам не может понять, какой именно. Это едва ли не сильнейшая проблема в нашем деле — когда не можешь сообразить, какие именно вопросы нужно задать. Отсюда и пляши.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, michael_isu, Вы писали:
EW>>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
_>Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
Её нужно либо решить коллективными усилиями, либо обойти. При этом совершенно необходимо избегать личных претензий и намёков на какое-нибудь там "недостаточное качество" специалиста. Перед любым спецом время от времени встают проблемы, которые не удаётся решить с наскока, это: а) нормально, б) не предсказуемо, в) ничего страшного. Не разрешаются только те проблемы, которые никто не разрешает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, michael_isu, Вы писали:
m> Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
Что важнее проблема или проект? Обычно этап проекта важнее. Нужно просто реализовать максимально простое решение проблемы с какими то ограничениями (ну типа, можно открыть только одно окно). Одновременно разработчику рассказать самому непонятливому о проблеме, чтобы он ее понял, затем описать проблему, пути решения, ограничения и пр. После обсудить все командой, наметить пути решения, возможно разбить на подзадачи и раздать их еще кому-то. Разработчику занятся другой задачей не забывая об этой. Обычно через какое-то время решение находится.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, michael_isu,
V_S>Гмм. А твоя-то роль в этой петрушке — какая? Если ты такой же рядовой разработчик или вообще сторонний наблюдатель, то — продолжай наблюдать, чем кончится, пусть проблему решают те, кому за это деньги платят. А вот если ты менеджер проекта — ты обязан вмешаться, если есть риск срыва сроков, это твоя служебная обязанность, за это ты деньги получаешь.
Моя роль — разработчик. И я порой попадаю в описанную ситуацию. Реакция менеджера — никакая, ждать. Периодически спрашивая не готово ли, с каждым разом всё с бОльшим недовольством ("ты же обещал сделать уже!"). Менеджер не в теме программирования, его роль — общение с заказчиком, разбиение ТЗ очередного проекта на итерации, декомпозиция задач, планирование итераций и т.д. (оценкой занимаются разработчики).
V_S>1. Откуда вообще взята магическая цифра "160 часов"? Это оптимистиная, пессимистичная или средняя оценка? Как она получена — почему не ровно 100 или 200? Риски при планировании рассматривались? Есть у тебя план управления рисками? Какие действия предусмотрены для риска "Риск срыва сроков"? Как он идентифицируется?
Берется ТЗ, разбивается логически на некоторые части, каждая из них разбивается на задачи, каждая задача оценивается. Проекты — веб-приложения, порталы. Оценивают обычно 2-3 разработчика, через estimation-покер. Ну т.е. такой-то раздел сайта — столько-то часов, такое-то проектирование — столько-то, такая-то страница столько-то и т.д. В сумме например получается 160, к примеру. Получается примерно средняя оценка. Риски менеджером учитываются, но понятное дело я о них не в курсе.
V_S>2. Почему "объяснения этого не пустые, но достаточно размытые"? Ты не можешь оценить реальное состояние дел? Привлеки специалиста более высокого уровня (эксперта), чтобы он оценил масштаб катастрофы, предложил способы преодоления проблемы и оценил сроки. Спецификация на модуль есть? Насколько подробная? Описывает ли она (и предусматривает ли вообще) те проблемы, с которыми столкнулся разработчик?
Например, при пополнении баланса пользователя на сайте он должен получать акты, в .doc и .xls-формате, либо в подобных, с которыми умеет работать MS Office. Нужно это реализовать, офиса на сервере нет и не будет. Задача для меня например в некоторой степени исследовательская. Ну или например нужно реализовать какую-нибудь простую онлайн-игру, типа морской бой, где нужны вобщем-то навыки ОО-дизайна, а придумать адекватную модель у человека не получается сходу.
Опишите целиком как вы решите описанную в первом посте проблему, по шагам, начиная от понимания, что время расходуется сверх запланированного и заканчивая тем, что задача закрывается. К кому обращаетесь, как перераспределяете план работ других людей, которых привлекаете к помощи, как контролируете что процесс сдвинулся, может ещё что-то.
В будущем мне нужно будет менеджерить проект, хочется знать как общественность поступает в таких ситуациях.
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, Vlad_SP, Вы писали:
_>Моя роль — разработчик. И я порой попадаю в описанную ситуацию. Реакция менеджера — никакая, ждать. Периодически спрашивая не готово ли, с каждым разом всё с бОльшим недовольством ("ты же обещал сделать уже!").
Надо не ждать вопросов, а информировать заранее о проблемах. Ну типа если надо сделать "печать" до 30 и проблем вроде не было, но вдруг 5-го обнаруживатеся, что задачу на которую планировался день можно решить только за неделю. Тогда это должен знать немедленно менеджер проекта, а не так что когда он спрашивает тебя 25 — ну будет готово в срок, ты говоришь нет.
_>Берется ТЗ, разбивается логически на некоторые части, каждая из них разбивается на задачи, каждая задача оценивается. Проекты — веб-приложения, порталы. Оценивают обычно 2-3 разработчика, через estimation-покер. Ну т.е. такой-то раздел сайта — столько-то часов, такое-то проектирование — столько-то, такая-то страница столько-то и т.д. В сумме например получается 160, к примеру. Получается примерно средняя оценка. Риски менеджером учитываются, но понятное дело я о них не в курсе.
Планирование конечно хорошо и полезно, но мне еще не попадался план который бы "работал правильно".
_>Опишите целиком как вы решите описанную в первом посте проблему, по шагам, начиная от понимания, что время расходуется сверх запланированного и заканчивая тем, что задача закрывается. К кому обращаетесь, как перераспределяете план работ других людей, которых привлекаете к помощи, как контролируете что процесс сдвинулся, может ещё что-то.
Не знаю как это можно описать в одном абзаце. Да и у каждого будут свои мнения. Ну и от конкретной команды очень много зависит. Нет единного поведения для всех случаев. Всегда нужно ориентироваться по конкретной ситуации. Что хорошо "работает" в одном месте может быть совершенно нерабочим в другом.
Мне кажется, важно иметь долгосрочные и краткосрочные планы. Долгосрочный план включает этапы "сдачи" проекта, он может корректироватья только в особо исключительных случаях. Краткосрочные планы ведут к концу этапа и могут корректироваться довольно оперативно. Я вообще сторонник top-down стратегиии (хотя можно некоторые элементы делать как down-top), поэтому на каждом этапе должна быть рабочая программа которая с каждым разом делает все больше и больше. Как минимум, можно ее регулярно сверять с планом.
_>В будущем мне нужно будет менеджерить проект, хочется знать как общественность поступает в таких ситуациях.
Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был.
Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
Здравствуйте, Vlad_SP, Вы писали:
V_S>1. Откуда вообще взята магическая цифра "160 часов"? Это оптимистиная, пессимистичная или средняя оценка? Как она получена — почему не ровно 100 или 200?
Всякий менеджер знает, что в человеко-неделе 40 часов, поэтому 4 человеко-недели выглядят в проджект-плане красивее, чем 2,5 или 5
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Сделай "дизайн ревью".
Пусть разработчик опишет у маркерной доски планируемые изменения с точностью до класса (модуля, что там в вашем языке есть). Пусть его слушают как минимум двое опытных коллег.
И пусть они объяснят ему, в чем проблема в его подходе. Или, если человек не может сам придумать решение, подумают все вместе.
А у него затруднения с подходом к решению есть. Просто он не знает, как об этом сказать.
Это может повторяться несколько раз, пока у проверяющих не останется замечаний. После этого, исполнителю будет довольно сложно объяснить затягивание, и даже если он раздолб — ему ничего не останется, кроме как либо сделать свою работу, либо себе харакири.
Тебе уже дали в ветке целую кучу полезных советов коллеги Геннадий Васильев, AlexNek, Gaperton...
Отмечу еще одну проблему, на которую тебе следует обратить внимание: _>Задача для меня например в некоторой степени исследовательская. Ну или например нужно реализовать какую-нибудь простую онлайн-игру, типа морской бой, где нужны вобщем-то навыки ОО-дизайна, а придумать адекватную модель у человека не получается сходу.
Отквоченное свидетельствует о смешении в одну работу задач исследовательских (ну или проектных), которые должны ответить на вопрос "как делать?", и задач чисто технических — когда уже точно известно, "как", и нужно только тупо педалить код. В этом, как мне представляется, и есть причина затягивания сроков — когда разработчику неясно, "как?".
Эти два типа задач абсолютно точно нужно разделить на отдельные работы (не смешиваем мух с котлетами!), причем, по результатам исследовательских или проектных работ должен появиться некий артефакт проекта — возможно, короткая пояснительная записка на 1-2 странички, отвечающая на вопрос "как?". И этот артефакт следует обсудить с коллегами — выполнить дизайн-ревью. По результатам — может быть несколько последовательных итераций дизайна. Ну, а далее — остается только реализовывать.... и тут "объяснения этого не пустые, но достаточно размытые" уже не прокатят.
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
У меня есть похожая ситуация. Я тоже разработчик, тоже не могу сделать продукт, затягиваю. Менеджер походит, пытается помочь, спрашивает когда. От слова когда я уже вздрагиваю. В конце концов он меня сдал — на совещании у руководства сказал что у меня недостаточная квалификация. Пришлось согласиться, потому что не нашел других оснований. Наняли другого человека, специалиста в данной области. Пошло немного быстрее.
Здравствуйте, net31, Вы писали:
N>Здравствуйте, michael_isu, Вы писали:
_>>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
N>У меня есть похожая ситуация. Я тоже разработчик, тоже не могу сделать продукт, затягиваю. Менеджер походит, пытается помочь, спрашивает когда. От слова когда я уже вздрагиваю. В конце концов он меня сдал — на совещании у руководства сказал что у меня недостаточная квалификация. Пришлось согласиться, потому что не нашел других оснований. Наняли другого человека, специалиста в данной области. Пошло немного быстрее.
Нормальный менеджер спрашивает, что нужно что бы закончить вовремя.
И на подобные вопросы не отвечают — не знаю. Надо объяснить проблему, чем сложнее объяснение, тем лучше
_>Берется ТЗ, разбивается логически на некоторые части, каждая из них разбивается на задачи, каждая задача оценивается. Проекты — веб-приложения, порталы. Оценивают обычно 2-3 разработчика, через estimation-покер. Ну т.е. такой-то раздел сайта — столько-то часов, такое-то проектирование — столько-то, такая-то страница столько-то и т.д. В сумме например получается 160, к примеру.
Напомню, что в результате такого мероприятия у вас получаются не часы, а "идеальные часы". Их ни в коем разе нельзя путать с реальными часами — теми, которых 40 в неделе. Скорость (burndown) нельзя авторитарно установить в "1:1" — но на основе сколь-нибудь длительных наблюдений можно посчитать (и после чего уже автоматом корректировать сроки). Напомню про "треугольник" (или "пирамиду" — кому как привычнее): если у вас фиксированы ресурсы (разработчики) и скоуп (фичи), нельзя зафиксировать время (и/или качество — если брать "пирамиду").
Короче говоря, на этапе оценки вы не можете получить настоящие "часы". А если у вас кроме этого проекта еще есть другие (например, багфиксы старых или консультирование коллег) — тем более.
_>Например, при пополнении баланса пользователя на сайте он должен получать акты, в .doc и .xls-формате, либо в подобных, с которыми умеет работать MS Office. Нужно это реализовать, офиса на сервере нет и не будет. Задача для меня например в некоторой степени исследовательская.
Ух, ну а тут вы вообще не можете давать оценки! Даже в идеальных часах! Один из хороших рецептов, практикующихся в Agile — выделить time box для создания прототипа (то самое "исследование"). Целью (target) этого исследования должна стать как раз ОЦЕНКА того, сколько делать настоящее (production grade) решение.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Эти два типа задач абсолютно точно нужно разделить на отдельные работы (не смешиваем мух с котлетами!), причем, по результатам исследовательских или проектных работ должен появиться некий артефакт проекта — возможно, короткая пояснительная записка на 1-2 странички, отвечающая на вопрос "как?". И этот артефакт следует обсудить с коллегами — выполнить дизайн-ревью. По результатам — может быть несколько последовательных итераций дизайна. Ну, а далее — остается только реализовывать.... и тут "объяснения этого не пустые, но достаточно размытые" уже не прокатят.
Артефакт необходим, если по этому "дизайну" ("эскизному проекту") будет работать кто-то кроме исполнителя.
Или (вторая ситуация), когда проверяющие проверяют удаленно.
Если же "дизайн" делается для себя, и проверяющие физически рядом — доклада у маркерной доски не просто достаточно — а так лучше будет.
Здравствуйте, SkyDance, Вы писали:
SD>Напомню, что в результате такого мероприятия у вас получаются не часы, а "идеальные часы". Их ни в коем разе нельзя путать с реальными часами — теми, которых 40 в неделе. Скорость (burndown) нельзя авторитарно установить в "1:1" — но на основе сколь-нибудь длительных наблюдений можно посчитать (и после чего уже автоматом корректировать сроки). Напомню про "треугольник" (или "пирамиду" — кому как привычнее): если у вас фиксированы ресурсы (разработчики) и скоуп (фичи), нельзя зафиксировать время (и/или качество — если брать "пирамиду").
SD>Короче говоря, на этапе оценки вы не можете получить настоящие "часы". А если у вас кроме этого проекта еще есть другие (например, багфиксы старых или консультирование коллег) — тем более.
А как быть тогда разработчикам? Если спускается сверху спецификация (состоящая из одних экранных форм), нужно оценить каждую форму в часах, и если сроки не выдерживаются (именно вот эти идеальные сроки) — прессуют по самое немогу.
