Отчёты за каждый день — это фигня, поскольку если есть чего сделанного, то это и так видно и на отчёт время жалко тратить, а если ничего не сделано, то грамотный косильщик всегда правдоподобное объяснение придумает...
Можно идти по тяжелому пути участия, когда вы постоянно с каждым разработчиком обсуждаете его работу, совместно ищите технические решения, коммутируете этого разработчика с другими и так далее. Вечером он может перед уходом с вами обсудить, что у него получилось, что нет, чего завтра делать и тому подобное...
Как вы будете планировать — это ваше дело. Можете конспектировать беседу с разработчиками, можете вести свой Project в каком-нибудь тулзе — это ваши проблемы. Главное, что ведение проекта в части соответствия факта плану — это работа ваша, а не разработчика, и заставлять его писать отчёты о проделанной работе — это вредная видимость управления.
Другими словами:
— будьте ближе к телу (общайтесь с разработчиком чаще, но не перегибайте палку);
— будьте в курсе дела (чем больше общаетесь, тем лучше видна текущая картина в целом);
— планируйте и сводите графики работ самостоятельно (не заставляйте разработчика этим заниматься — ему проще рассказать, чем написать... Если бы было проще написать, то он был бы руководителем, а вы разработчиком);
— если кто-то хочет нагрузить вашего человека дополнительной работой, то жёстко указывайте на возможный срыв сроков (защищайте работника)...
А техника изготовления за пару недель прототипа, моделирующего всю сложную систему, Вам не известна. Если Вы не занимались областью — берете время на ее изучение (две недели, месяц, полгода — сколько надо) — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать девелопмент план на полгода, поскольку для Вас уже не будет неизвестных мест.
GUID wrote: > > Здравствуйте, kittown, Вы писали: > > А техника изготовления за пару недель прототипа, моделирующего всю > сложную систему, Вам не известна. Если Вы не занимались областью — > берете время на ее изучение (две недели, месяц, полгода — сколько надо) > — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать > девелопмент план на полгода, поскольку для Вас уже не будет неизвестных > мест.
Я говорил о крайних проблемных и неоднозначных случаях, а не о
нормальном ходе разработки. Конечно, по уму выделяется достаточно
времени и все просчитывается заранее, включая написание прототипа.
И еще в устоявшемся процессе разработке работник точно понимает,
что именно ему хотел сказать начальник. Я лично регулярно теряюсь,
с какой именно степенью буквальности надо воспринимать сказанное
сверху. Приходится кучу дополнительных вопросов задавать.
Предпочитаю брутальную прямоту, буквализм, а если уж приходится
делать иногда кривость (by design — именно этого и просят), то
и сомнительный черный юмор. Иначе мозги клинит — не поймешь,
когда можно особо не напрягаться, а когда делаем серьезную
вещь в сжатые сроки и нужно выкладываться по полной.
Hint: нельзя выкладываться на 100% постоянно, наступает burnout.
Здравствуйте, Constructor, Вы писали:
C>Здравствуйте! C>В конторе складывается такая ситуация.
C>По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает. C>Поднимается вопрос о том, что разработчик — разгильдяй.
C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи. C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.
C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!
A> Похоже на то, что такая ситуация больше зависит от конторы. В некоторых,
насколько мне известно, она возникает постоянно. И проблема, насколько мне известно,
не в разработчике. Боюсь, что такой контроль осуществлять очень сложно.
И ежеXXX- ые отчеты тут не очень помогут. Вообще это интересная ситуация — когда
есть один программист, у него есть, как минимум один, начальник, и т.д. А Вы не пробовали
изменить структуру? В некоторых из серьёзных софт — контор большинство вопросов решается
исключительно людьми, сведущими в разработке.
Здравствуйте, Constructor, Вы писали:
C>Здравствуйте! C>В конторе складывается такая ситуация.
..... C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!
Отличить действительно нелегко, но вот несколько замечаний из моего личного опыта:
1. Планируется только обозримый период — месяц, в крайнем случае квартал;
2. Этот месяц заполняется плотно, т.е. если работа больше месяца, выделяется ее часть, оценочно по длительности на месяц, если короче — ставится еще одна задача;
3. Все постановки письменно за подписями как руководителя так и исполнителя;
4. Отчет по каждой задаче. Если задача закончена, отчетом является документация к программе(задаче), если нет — пояснительная записка с описанием завершенной части.
И еще. Ни в коем случае нельзя требовать отчета ежедневного, еженедельного и пр.Со временем поймешь, что это дискредитирует в первую очередь тебя, как руководителя, а исполнитель очень быстро научится баки забивать, и только.
Отчеты же о сделанных задачах вкупе с постановками — есть объективное подтверждение квалификации исполнителя.
Главное — научись планировать, остальное приложится.
Можно я выскажусь с точки зрения разработчика. Ненавижу планы!!! Ладно еще, когда тебе говорят — вот тебе два месяца — напиши за это время программу, но когда заставляют расписывать планы по дням, а то и по часам, то это КОШМАР. Честное слово, это блокирует всю работу. Это еще можно делать, когда работа тупая, механическая, но когда работа творческая........ И вместо того, чтобы спокойно окунуться в процесс разработки ты решаешь ребусы: как составить эти планы, чтобы начальник не придрался, как отчитываться по ним. Например, неделя ушла на отлавливание какого-нибудь злостного глюка в программе. И что писать в отчете? Напишешь как есть, начальник точно разгильдяем посчитает, приходится что-то придумывать, выкручиваться. Как можно разделить задачу?
У нас принято делить по формам. Но разве можно сделать сначала одну форму от начала до конца, потом другую. Все же взаимосвязано. Да и не в формах дело, вначале какие-то общие принципы придумываешь, стиль программы в конуе концов. И как это все в планах учитывать???
В общем, КОШМАР!!!
Жизнь — это сражение, которое ты всегда проигрываешь.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, BalTun, Вы писали:
BT>>А может, г-н Конструктор, причина в вашей некомпетентности как управленца ? BT>>Может Вы вовсе не то контроллируете и Вам стоит подтянуть свой профессиональный уровень, а не искать причину в подчиненных ?
Д>Как известно, карьерный рост продолжается, пока работник не достиг своего уровня некомпетентности. А когда достигнет, тогда он остается работать на текущей должности Д>(C) законы Мерфи
Я только вот чего не понимаю, какая разница "разгильдяй" человек или нет ? Если это трудолюбивое ничтожество то он лучше талантдивого разгильдяя ?
Какая разница ?
Надо смотреть на работу которую они выполняют, и ВСЕ.
То есть оценивать ПРОДУКТИВНОСТЬ а не СТАРАНИЯ.
Я при поступлении на работу СРАЗУ оговариваю что 8 часов в сутки я не могу продуктивно работать , только 3-4 часа. Остальное время я трачу на обсуждение самообучение исследования отдых и т.д. (на порно сайты не хожу).
Если меня кто то назовет разгильляем , я обижусь. Это просто мой ВЫСОКО ПРОДУКТИВНЫЙ режим работы.
Здравствуйте, minorlogic, Вы писали:
M>Я только вот чего не понимаю, какая разница "разгильдяй" человек или нет ? Если это трудолюбивое ничтожество то он лучше талантдивого разгильдяя ? M>Какая разница ? M>Надо смотреть на работу которую они выполняют, и ВСЕ.
Я ничего против не имел бы против талантливого разгильдяя чье разильдяйство выражается в том что он работает 2 часа в день, но когда разгильдяйство проявляется в том что человек в принипе не способен самостоятельно работать и выливается это в то что за ним нужно код читать то нафиг-нафиг. Пусть хоть таланливей Энштейна будет — пусть хоть в дворники хоть в ученые идет, лишь бы подальше.
M> То есть оценивать ПРОДУКТИВНОСТЬ а не СТАРАНИЯ.
Это точно.
M>Я при поступлении на работу СРАЗУ оговариваю что 8 часов в сутки я не могу продуктивно работать , только 3-4 часа. Остальное время я трачу на обсуждение самообучение исследования отдых и т.д. (на порно сайты не хожу). M>Если меня кто то назовет разгильляем , я обижусь. Это просто мой ВЫСОКО ПРОДУКТИВНЫЙ режим работы.
Он у всех такой. Brain Time vs Body Time по книжке Peopleware 50% почти никогда не превышает. Обычно он меньше. Так что можешь не оговаривать — все и так знают.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Dyusha, Вы писали:
D>Здравствуйте, Constructor, Вы писали:
D>Можно я выскажусь с точки зрения разработчика. Ненавижу планы!!! Ладно еще, когда тебе говорят — вот тебе два месяца — напиши за это время программу, но когда заставляют расписывать планы по дням, а то и по часам, то это КОШМАР. Честное слово, это блокирует всю работу. Это еще можно делать, когда работа тупая, механическая, но когда работа творческая........ И вместо того, чтобы спокойно окунуться в процесс разработки ты решаешь ребусы: как составить эти планы, чтобы начальник не придрался, как отчитываться по ним. Например, неделя ушла на отлавливание какого-нибудь злостного глюка в программе. И что писать в отчете? Напишешь как есть, начальник точно разгильдяем посчитает, приходится что-то придумывать, выкручиваться. Как можно разделить задачу? D>У нас принято делить по формам. Но разве можно сделать сначала одну форму от начала до конца, потом другую. Все же взаимосвязано. Да и не в формах дело, вначале какие-то общие принципы придумываешь, стиль программы в конуе концов. И как это все в планах учитывать??? D>В общем, КОШМАР!!!
Планы вещь нужная и полезная. Без них проблематично что-либо сделать, кроме непосредственного процесса разработки (имеется ввиду бизнес-составляющая IT проекта). Нужно просто составлять их правильно. Если неоднократно сроки срываются из-за увеличения времени на отладку и прототипирование, то нужно увеличить время на эти действия в планах.
Прикиньте, насколько отличается у вас планирование работ от, например, рекомендаций классиков (например, Брукса). Если отличается сильно — есть повод задуматься и поговорить с теми, кто такие планы составляет.
- проектирование — 1/3,
— написание команд -1/6,
— отладка компонент и отдельных подсистем — 1/4,
— системная (комплексная) отладка всех компонент — 1/4.
Это разбиение отличается от общепринятого по нескольким важным показателям:
— доля, отведенная проектированию, больше обычного. Но даже в этом случае времени едва хватает на написание подробных и надежных спецификаций и вовсе недостает на разработку и внедрение существенно новых методов;
— половина времени отводится на отладку написанной программы, что гораздо более обычного;
— часть, которую легко оценить, т. е. собственно написание команд, занимает только одну шестую графика.
Здравствуйте, Spidola, Вы писали:
S>Планы вещь нужная и полезная. Без них проблематично что-либо сделать, кроме непосредственного процесса разработки S>(имеется ввиду бизнес-составляющая IT проекта). Нужно просто составлять их правильно.
А вот кто их должен правильно составлять?
Если я нанятый разработчик — я готов в конце дня вот в таком вот тракере
Здравствуйте, GUID, Вы писали:
GUI>Здравствуйте, kittown, Вы писали:
GUI>А техника изготовления за пару недель прототипа, моделирующего всю сложную систему, Вам не известна. Если Вы не занимались областью — берете время на ее изучение (две недели, месяц, полгода — сколько надо) — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать девелопмент план на полгода, поскольку для Вас уже не будет неизвестных мест.
Нередко вопрос "сколько на это потребуется времени" задаётся потому, что хочется понять, насколько будет выгодно делать данный проект (успеем по срокам, уложимся в бюджет и т.п.).
Если каждый проект будет предварятся полугодом изучения новой темы и месяцем-двумя написания прототипа, то к моменту готовности плана такой проект, скорее всего, уже выйдет за рамки бюджета или сроков, и никому не будет нужен.
Здоровый авантюризм порой лучше тщательной длительной подготовки.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, SergeySPb, Вы писали:
SSP>>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме, SSP>>а отчёты получать в письменной.
O>Не всегда. У нас таски раздаются через трэкер. В конце дня отчет о том, какие таски закрыл, какие подвисли. Если таска большая (это редкость) — сколько % по ней сделано.
Надо нанимать тогда еще специально обученный персонал, который эти самые таски будет составлять Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?
На самом деле специфика везде разная. Смотря что за контора, чем занимаются, что за отдел и проч...
Почитал советы. Долго думал Роботизм какой-то советуют
А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.
postmaster wrote: > > GUI>А техника изготовления за пару недель прототипа, моделирующего всю > сложную систему, Вам не известна. Если Вы не занимались областью — > берете время на ее изучение (две недели, месяц, полгода — сколько надо) > — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать > девелопмент план на полгода, поскольку для Вас уже не будет неизвестных > мест. > > Нередко вопрос "сколько на это потребуется времени" задаётся потому, что > хочется понять, насколько будет выгодно делать данный проект (успеем по > срокам, уложимся в бюджет и т.п.).
Это в общем-то само собой очевидно. Но важна же не только цель вопроса,
а и его следствия и прочие сопутствующие факторы. Самая большая
ошибка планировщиков — не учитывать стоимость планирования, как
в явном виде (время, зарплата планировщика), так и косвенном (халтура
с выдержкой сроков при невозможности за эти сроки сделать нормально,
или просто замедление разработки из-за невменяемого порядка этапов
разработки в плане, или банальная нервотрепка с повышенным burnout).
Хороший менеджер всегда следит, где сегодня находится золотая середина,
и действует соответственно. Завтра будет смотреть, где она будет завтра.
> Если каждый проект будет предварятся полугодом изучения новой темы и > месяцем-двумя написания прототипа, то к моменту готовности плана такой > проект, скорее всего, уже выйдет за рамки бюджета или сроков, и никому > не будет нужен.
Были проекты именно с такими временными характеристиками, вот только
изучение совмещается с прототипированием и проектированием.
> Здоровый авантюризм порой лучше тщательной длительной подготовки.
Если только стоимость ошибки не превышает возможную прибыль. Бывает
как в случае порчи репутации фирмы, так и в случае нестабильности
продута при обновлении. Начиная с АЭС и заканчивая банкоматами.
Здравствуйте, SergeySPb, Вы писали:
SSP>Здравствуйте, Spidola, Вы писали:
S>>Планы вещь нужная и полезная. Без них проблематично что-либо сделать, кроме непосредственного процесса разработки S>>(имеется ввиду бизнес-составляющая IT проекта). Нужно просто составлять их правильно.
SSP>А вот кто их должен правильно составлять? SSP>Если я нанятый разработчик — я готов в конце дня вот в таком вот тракере
отметить что было сделано за день. SSP>Заполнить этот тракер заданиями, расставить их приоритеты — разве этим разработчик должен заниматься?
Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:
1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH
[]
S>Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода: S>1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER S>2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER S>3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH
Есть еще как минимум один вариант:
4) Все таски типичные и время выделяется правильно, но маленькая зарплата. ШЕФ ЖМОТ.
Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?
