Учимся оценивать проекты

Здесь мы обсуждаем вопросы совместной работы в команде и с командами (Scrum, Kanban, TOC и прочий Lean)
Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

Stac писал(а):
virusde писал(а):
Stac писал(а):Оценка (с позиции Насти) это стресс.
Да ну, бросьте, для меня оценивание это как challenge и чем больше (длиннее и сложнее) проект, тем выше адреналин, стараюсь потом свои оценки ретроспективно проверять.
Секундочку, это вы Настя? :) Челлендж это здорово, но не вариант - не масштабируется. И самая распространенная причина смерти это косвенно подтверждает.
Тут ваши статистические методы не дадут вам ответ ;-)
Stac писал(а):
virusde писал(а):Ещё нужно принять как аксиому - ПМ-ам всегда нужны сроки, потому что у ПМ-ов есть ПМ-ы, которым нужны сроки, и т.д., иначе будет как в известном видео http://www.youtube.com/watch?v=4u5N00ApR_k :)
Забавный ролик :)
Мне тоже нравится, особенно интонация. :)
Stac писал(а): А можно ли уточнить аксиому до "ТОЛЬКО ПМ-ам всегда нужны сроки, потому что у ПМ-ов есть ПМ-ы, которым нужны сроки, и т.д."?
Потому что я не вижу тут, зачем бы оценка была нужна Насте. Тем более регулярная (частая) и опережающая, как вы предлагаете.
Почему ПМ сам не дает своему руководству оценки, тем более, что он подкован в разных специальных методах для этого?
Возможно, у ПМ нет каких-то четких критериев для оценки. Но... их нет и у исполнителя.
Тут действует порочная практика искоренить которую довольно проблематично в любой организации, когда идущая снизу оценка берётся для закладывания буфера вышестоящим ПМ-ом и транслируется ещё выше, там где есть конечный её потребитель.
Но (сразу хочу оградить вас от дальнеших споров о полезности и бесполезности этих ритуалов) в любом случае, какой бы опыт не был у ПМ-а, сколько бы он книжек не прочитал и тренингов не посетил, только разработчик зная свою скорость и текущую ситуацию в проекте/жизни может дать наиболее реалистичную (но как правило излишне оптимистичную) с его точки зрения оценку. А дальше конечно могут запускаться механизмы "давления" и прочие менеджерские уловки. Но мы не про это тут -- "Зачем нужны оценки", мы про то "Как выполнять оценки и с высокой вероятностью в них попадать".
Stac писал(а): Интересно, устроила бы ПМ автоматическая оценка (рассчитанная программой или взятая с потолка), если бы она удовлетворяла требованиям - была частой и опережающей?
Лично я собираюсь проверить это на своих проектах в ближайшее время.
Но интереснее, что вы скажете по этому поводу.
Если это будет самообучающаяся на предыдущем опыте этого разработчика система, то думаю устроила бы, но в неё слишком много параметров придётся вбивать, а на выходе может получиться 42, что довольно сложно потом будет дешифровать.
Меня лично, а я из тех ПМ-ов с плёткой, устроила бы любая оценка, причём чем хорош agile, что ты можешь сказать, что сложность невелика, но осталось 8 часов, через день сказать, не-е, ещё точно 8-10 часов, а потом сказать, походу ошибся, ещё 12 часов и это будет восприниматься нормально, потому что shit happens и разработчики тут не всегда виноваты.

ТыжПрограммист
Сообщения: 1
Зарегистрирован: Ср июл 01, 2015 2:20 pm

Re: Учимся оценивать проекты

Сообщение ТыжПрограммист »

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

Еще хотелось бы добавить, что многое зависит от ваших доработок. Какое их количество, как много стандартного функционала они затрагивают.

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

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

Всё правда и я к этой же идее и пришел, затеяв эту переписку.
Не нужно тянуть с накатыванием обновлений, а идеально было бы, чтобы продвинутые ребята из 1С дали бы доступ на каком-нить гитхабе в транк, чтобы чаще оттуда их изменения забирать.
Спасибо за совет ;)

Stac
Сообщения: 81
Зарегистрирован: Чт авг 06, 2015 9:11 pm

Re: Учимся оценивать проекты

Сообщение Stac »

virusde, я все-таки не понимаю, зачем вам мучить Настю. Из ваших ответов мне можно видеть, что (а) есть цепочка ПМ-ов, которые перезакладываются по срокам так, что цифра, названная исполнителем, становится малозначительной, (б) shit happens и это не связано с опытом исполнителя (или связь не очевидна и ее нельзя использовать).

И в (а) и (б) оценка разработчика не значима или малозначима (ни на что не влияет).

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

Дополнения "излишне оптимистичная" и " с его точки зрения" еще снижают значимость того, что скажет Настя.

Кроме того, в процитированном утверждении, на мой взгляд разработчика кроется сразу несколько ошибок:
1) разработчик не знает свою скорость (такое понятие вообще не определено) ... это какая-то ПМовская абстракция, видимо.
2) знание текущей ситуации не помогает в оценке срока, когда меняется или плохо определен конечный результат (для разработчика это так почти в 100% случаев, потому что любой написанный код может быть доработан и улучшен),
3) разработчик не может стабильно давать реалистичную оценку - для этого никогда нет достаточно данных (хотя бы из-за 1) и 2) )

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

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

Вместо того, чтобы отправлять Настю на семинары, не лучше ли вам освоить программирование. Тогда вы сами сможете давать наиболее реалистичную оценку, зная текущую ситуацию.
(Я лично брал курс по программированию на 1С8 лет 10 назад, когда был сэйлзом и не понимал, почему для нашего 1С программиста (тоже женщины) все долго и сложно).

Что думаете?

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Учимся оценивать проекты

Сообщение Максим Дорофеев »

virusde писал(а):Не нужно тянуть с накатыванием обновлений, а идеально было бы, чтобы продвинутые ребята из 1С дали бы доступ на каком-нить гитхабе в транк, чтобы чаще оттуда их изменения забирать.
Спасибо за совет ;)
На сколько мне известно, ребята из 1С:Бухгалтерии релизятся раз в месяц. А еще у них есть песочницы. Вам же Бухгалтерия нужна, да?

И я бы задумался над тем, что пишет Stac :) А то действительно получается: Настя и разрабатывает, Настя и планирует, а для чего вообще в этой компании ПМ-ы существуют? Или они не ПМ-ы вовсе, а так - каста передастов (с)? ;)

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

Отвечу вам обоим (Stac, cartmendum), и предлагаю эту ветку дискуссии перместить во Флейм, поскольку вы дискутируете со мной на тему "Нужна ли вообще оценка разработчиком своих задач", это пожалуй делать бесполезно, поскольку в этом у меня нет сомнений и если бы они появились, я бы наверное так и сформулировал тему. Принимаю то, что не всегда оценки близки к реальности, но они точно нужны, чтобы понимать, что мы успеем доставить к определённому сроку. Либо вы живёте (жили) в слишком комфортных условиях, где можно заниматься чем угодно, сколько угодно времени. Но ведь это не так?

Что касается перекладывания ответственности, то тут моё мнение сводится к тому, что если разработчик не научится делать оценки, принимать на себя обязательства, то мне сложно будет рассматривать его кандидатуру в ПМ-ы, вот если оно ему не нужно – опускаю руки.

По поводу курсов программирования и 1С – мне достаточно знаний чтобы понять сколько по времени займёт кодирование/перенос или обновление, но пока Настя погрузит меня во все детали, я сам смогу это проделать, но как бэ зачем разработчики тогда?

Ещё раз возвращаю вас в контекст, это был стендап, у Насти не было текущей оценки, она знала, что сделана часть работы, её просят дать оценку, но чтобы ей это сделать ей нужно объять весь скоуп видимых ей задач, прикинуть сколько на него уйдёт времени и в следующий раз придти подготовленной и сообщить оценку того, сколько времени осталось для выполнения видимого ей скоупа задач. Вот тут накидывайте идей, пожалуйста, а не сводите дискуссию к ПМ-ам передастам и бесполезности оценки. :)

Либо если я заблуждаюсь, давайте рисовать тучу. ;)

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

cartmendum писал(а):
virusde писал(а):Не нужно тянуть с накатыванием обновлений, а идеально было бы, чтобы продвинутые ребята из 1С дали бы доступ на каком-нить гитхабе в транк, чтобы чаще оттуда их изменения забирать.
Спасибо за совет ;)
На сколько мне известно, ребята из 1С:Бухгалтерии релизятся раз в месяц. А еще у них есть песочницы. Вам же Бухгалтерия нужна, да?
Нее, у нас 1С:Документооборот, но не суть, проблема общая у 1С решений.
cartmendum писал(а):И я бы задумался над тем, что пишет Stac :) А то действительно получается: Настя и разрабатывает, Настя и планирует, а для чего вообще в этой компании ПМ-ы существуют? Или они не ПМ-ы вовсе, а так - каста передастов (с)? ;)
Пытаюсь, не выходит, пока сводится к тому, что разработчики вообще не должны давать оценки. Неприемлемо, хочу знать когда закончится, пусть с невысокой вероятностью, но хочу.

Stac
Сообщения: 81
Зарегистрирован: Чт авг 06, 2015 9:11 pm

Re: Учимся оценивать проекты

Сообщение Stac »

1) Конечно все мы доставляли в срок, хоть когда-то. Но часто доставляли не то, что планировали.
Бюро Горбунова популяризирует метод ФФФ (fix time, fix budget, flex scope), который позволяет доставлять в срок. Это может быть вам давно известно и не вполне подходить под ситуацию, но тем не менее... любопытно.

2) Если вы рассматриваете кандидатуру Насти в ПМ, то требовать знаний от неё разумно. Но все же сложно разработчику оценить именно свою работу. Попробуйте, справится ли она с оценкой других программистов. Это может быть действенней, потому что те факторы, о которых я писал выше не будут влиять.

3) Отсылая вас к курсам, я не имел в виду, что вам и программировать потом нужно. Вы бы лучше поняли своих коллег. Мне кажется часть проблем в области психологии. Я прямо по-человечески понимаю вашу Настю, вспоминая моменты когда с меня требуют оценку.

А это было буквально сегодня. Я сказал, что сегодня-завтра будет готово. Но потом ничего по проекту не делал, а сегодня уже закончилось. Кроме того, вместе с запросом оценки мне было выдано пяток новых задач, которые в оценку сообщенную ПМ не вошли, но на мою собственную оценку повлияли -- пришлось часть ранее запланированных задач сдвинуть. Т.е. моя оценка стала не верной, сразу же. Фиговое это ощущение.
Я могу плюнуть и завтра спокойно дать новую оценку. А как такое воспринимают женщины загадка, хотя, наверное, как-то по-другому.

4) Для продолжения дискуссии я,скорее всего не компетентен. Озвученная проблема понятна, но решения у меня нет.
Хотя я и пытаюсь что-то делать ... экспериментирую так сказать.
Во-первых, я отказался от какой-то более-менее точной оценки задач по времени, сведя все к двум классам - быстрые (30-60 мин) и средние (от 2-4 часов). Подслушал у Умпутуна в одном из подкастов.

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

Важно: (а) не морочить голову и не отвлекаться от основной работы (а она у меня, как и у Насти не в планировании), (б) снижать погрешность в оценке за счет декомпозиции до достаточно маленьких задач (но не слишком).

Непосредственно до того, как я пришел к этим тезисам (а это буквально июль-август). Я пытался давить на ПМ, принимать от него только одну задачу за раз, и не принимать новую, пока не выполнена старая.. Задачи быстрые -- соответственно никаких проблем с оценкой - 0,5-1 час.

Но опыт оказался неудачным. ПМ считает, что работа замедлилась, потому что он, приняв выполненную задачу не может сразу выдать следующую.

И вот мы каждый ведем по списку задач. Он в MS Project или в чем-то подобном, я - в текстовом файле.

Кстати, у вас с Настей список задач одинаковый? Потому что у меня в существенной часть проектов это не так. ПМ далек от мира разработки и формулирует свои задачи часто в бизнес-терминах. Мне для себя приходится переформулировать.

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

Stac писал(а):1) Конечно все мы доставляли в срок, хоть когда-то. Но часто доставляли не то, что планировали.
Бюро Горбунова популяризирует метод ФФФ (fix time, fix budget, flex scope), который позволяет доставлять в срок. Это может быть вам давно известно и не вполне подходить под ситуацию, но тем не менее... любопытно.
Отличный метод, но опять же тут слабо применим, мы закрепили scope, бюджет и время не волнует, но совсем от оценок уйти не можем, конец должен быть виден где-то.
Stac писал(а): 2) Если вы рассматриваете кандидатуру Насти в ПМ, то требовать знаний от неё разумно. Но все же сложно разработчику оценить именно свою работу. Попробуйте, справится ли она с оценкой других программистов. Это может быть действенней, потому что те факторы, о которых я писал выше не будут влиять.
Пробовали, как раз на быстрых и средних задачах в вашей терминологии, она уже занималась постановкой и тут проблем не возникает, проблемы как раз с "долгостроем".
Stac писал(а): 3) Отсылая вас к курсам, я не имел в виду, что вам и программировать потом нужно. Вы бы лучше поняли своих коллег. Мне кажется часть проблем в области психологии. Я прямо по-человечески понимаю вашу Настю, вспоминая моменты когда с меня требуют оценку.
Stac, да я и так на одной с ними волне, бок о бок работаем, даже несмотря на то, что я из мира .net.
Stac писал(а): А это было буквально сегодня. Я сказал, что сегодня-завтра будет готово. Но потом ничего по проекту не делал, а сегодня уже закончилось. Кроме того, вместе с запросом оценки мне было выдано пяток новых задач, которые в оценку сообщенную ПМ не вошли, но на мою собственную оценку повлияли -- пришлось часть ранее запланированных задач сдвинуть. Т.е. моя оценка стала не верной, сразу же. Фиговое это ощущение.
... это уже про впихивание невпихуемого. В этом же кейсе новые задачи могут рождаться только в рамках этого обновления, никаких других нет, просто копать можно и дна не видно, но геологи ведь продвинулись и надо сказать есть результаты :)
Stac писал(а): Я могу плюнуть и завтра спокойно дать новую оценку. А как такое воспринимают женщины загадка, хотя, наверное, как-то по-другому.
В этом и прелесть ежедневных стэндапов, что можно оперативнее информацию давать и получать и все довольны. Не, у вас не так?
Stac писал(а): 4) Для продолжения дискуссии я,скорее всего не компетентен. Озвученная проблема понятна, но решения у меня нет.
Хотя я и пытаюсь что-то делать ... экспериментирую так сказать.
Во-первых, я отказался от какой-то более-менее точной оценки задач по времени, сведя все к двум классам - быстрые (30-60 мин) и средние (от 2-4 часов). Подслушал у Умпутуна в одном из подкастов.
Во-вторых, от ПМ я стараюсь принимать только быстрые задачи. При поступлении средней она декомпозируется на быстрые.
Да, можно оценивать и в стори поинтах и других единицах времени/сложности, но оценка должна быть, пусть и неточная.
Stac писал(а): В-третьих, (это еще не реализовано, но уже очень хочется) я буду давать ПМ оценку автоматически - зачем грустным взглядом окидывать скоуп видимых задач, когда это может сделать компьютер. Да еще и письмо высылать каждый день при изменении ситуации.
ПМ-ы любят человеческое общение, рано или поздно всё равно будет приходить и спрашивать, ну чего, когда закончим? :)
Stac писал(а): Важно: (а) не морочить голову и не отвлекаться от основной работы (а она у меня, как и у Насти не в планировании), (б) снижать погрешность в оценке за счет декомпозиции до достаточно маленьких задач (но не слишком).

Непосредственно до того, как я пришел к этим тезисам (а это буквально июль-август). Я пытался давить на ПМ, принимать от него только одну задачу за раз, и не принимать новую, пока не выполнена старая.. Задачи быстрые -- соответственно никаких проблем с оценкой - 0,5-1 час.

Но опыт оказался неудачным. ПМ считает, что работа замедлилась, потому что он, приняв выполненную задачу не может сразу выдать следующую.
И вот мы каждый ведем по списку задач. Он в MS Project или в чем-то подобном, я - в текстовом файле.
Опять же, я своими проблемами, если Настя сделает две задачи в рамках обновления, я их не смогу принять, я даже их не увижу, она это делает в своей разработческой базе, поэтому я cartmendum и писал в начале, что не вижу смысла в декомпозировании пользовательской истории (для меня) на несколько, а только декомпозирование её на отдельные таски (checklist), которые Настя сможет оценить, потому как они либо мелкие, либо средние, а уж потом можно собрать их все в кучу и получить хоть примерную общую оценку для этой пользовательcкой истории.
Stac писал(а): Кстати, у вас с Настей список задач одинаковый? Потому что у меня в существенной часть проектов это не так. ПМ далек от мира разработки и формулирует свои задачи часто в бизнес-терминах. Мне для себя приходится переформулировать.
Да, живём в одном баг-трекере, но возможно у Насти есть ещё более мелкий список подзадач для задач из пользовательской истории обновления, узнаю завтра :)

Stac
Сообщения: 81
Зарегистрирован: Чт авг 06, 2015 9:11 pm

Re: Учимся оценивать проекты

Сообщение Stac »

Я работаю удаленно последние несколько лет, поэтому ежедневных стендапов лишен (а до этого они не были распространенной практикой). У меня нет мнения о том, насколько они полезны или нет.
Но кажется, что если разработчик должен слушать, ежедневные встречи однозначный плюс, а если должен докладывать - то весьма вероятно, что это минус.

Что у нас остается по кейсу -- задачи. Все свелось к задачам.

Если "долгострои" вызывают проблемы, то их отсутствие жизненно важно. Понимает ли это Настя? Хорошо ли она делит задачи на быстрые, средние, большие? Хорошо ли она декомпозирует большие задачи?

Если у вас один баг-трекер, то может быть еще такое - возникнет в ходе работы задача, которую нельзя или сложно отнести к какой-то одной (или никакой) задаче в баг-трекере, ни к одной пользовательской истории.

Это когда трогаешь код в одном месте, а ломается в другом.

(Пример из моего позавчера - Заказчик посчитал, что он должен добавлять новых Клиентов в CRM без e-mail ... пустяк, сделали соответствующее поле в БД и на формах не обязательным для заполнения. А вот, то это затронуло все систему уведомлений Клиентов, назначения встреч и обратной связи, ни Заказчик ни ПМ подумать не могли. Как и я момент предварительной оценки. -- в спсике задач ПМ не появилось ничего нового из-за этого. Но он не преминул удивиться почему оценка была впятеро превышена. )

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

Ответить