Здравствуйте, Sammo, Вы писали:

S>Причем первоначально везде была ситуация 2, потом везде была ситуация 1. Потом в каких-то системах так, в других этак. Предварительно — сильно зависит от срочно реализации и важности системы. Там где сопровождение занимается и разработкой немного проще с постановкой задач + быстрее с реалзиацией. Они обычно работают по Канбану. Там, где разработка тдельно — они работают по Скраму и в недельный спринт внепланово берут только мажорные баги (под это дело им всегда резервируют некоторое время).
S>Вот со второй группой не готов сказать — как они работают (к ним не имею отношения). Насколько я знаю, жира (где сделали доску для Канбана)
S>Там, где разработка и поддержка отдельно — у поддержки только Итилиум, у разработки только Жира. Передачи задач нет. Есть доп. база на основе Жиры — учет багов. Вот по ним есть взаимосвязь: инцидент в Итилиуем, бага в жире, задача для разработчика в жире.
S>При передаче нового существенного функционала документация (если она есть, что бывает не всегда ) передается разработкой в поддержку и та ведет ее в своем спейсе в конфлюенце.
S>Т.е. это ситуация, когда разработка и поддержка совсем отдельные подразделения. Есть недостаток — они несколько конкурирующие, поэтому бывают и внутренние разборки (например, по качеству, по багам и т.п.)

Хм.
Получается нужна некая комплексная система из нескольких баз данных по задачам:
1) база запросов (это типа ServiceDesk)
2) база с декомпозицией запросов на задачи для планирования и назначения исполнителям (это система планирования + трекер типа Jira)
3) база с хронологией выполнения, выше писали что в Jira это реализовано как "технические подзадачи"

Так получается?

Здравствуйте, diez_p, Вы писали:

_>Использовал джиру и trac — обе вещи хороши, если обновлять раз в день — чаще уже хуже. Хотя в джире можно трекать потраченное время. Думаю можно написать приложение для джиры которое позволяет удобно трекать время по таскам.
А зачем trac использовали, если в джире можно трекать?

Здравствуйте, velkin, Вы писали:

V>На этот вопрос уже ответил, или ставим систему управления проектами и включаем функциональность контроля времени, или никак.
что за система?

Здравствуйте, bkat, Вы писали:

E>>И эта же задача поступает программисту (вернее не программисту, а специалисту поддержки), то есть она не детализируется, она в исходном виде поступает специалисту.
E>>Поэтому специалист сам ее должен детализировать

B>Отлично.
B>И что вы делаете с тем, что специалист напланировал?
B>Заносите в JIRA или подобное?
B>Этого не достаточно?

Сейчас ничего.
Я имел ввиду, что специалисту поступает задача, она заносится в систему типа Jira, но без детализаций.
Дальше от него требуется выполнить эту задачу, поставить отметку о выполнении и трудозатратах.

То, что я сказал "специалист сам ее должен детализировать" — это я имел ввиду, что он сам для себя умственно продумывает способ решения.
То есть сейчас эту "умственную детализацию" мы никуда не пишем.

Здравствуйте, DiPaolo, Вы писали:

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

DP>Для эксперимента советую попробовать самому записвать лог своей работы. Я как-то делал так, чтобы понять, куда тратится время. Во-первых, через пару недель надоест. Во-вторых, это убивает весь полет фантазии и желание работать. И самое главное, как уже писали — это нафиг не нужно.
Я же писал, что вообще мы записываем ход работы, но с помощью неудобных средств (блокноты, ексель).
Надоест — не надоест — это не имеет значения.
Мы многие вещи делаем не потому что хочется, а потому что надо.
И на фантазию и желание работы это никак не влияет.
У вас фантазия пропадает после например чистки зубов?

Здравствуйте, DiPaolo, Вы писали:

DP>Извините, конечно, но складывается ощущение, что у руководителя какие-то свои тараканы на тему перфекционизма и педантизма. (Так и не понял, руководитель Вы или подчиненный)

Я — среднее звено.

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

А наше руководство и я в том числе, заинтересовано в том, чтобы и специалисты и заказчики были довольны друг другом.

Здравствуйте, DiPaolo, Вы писали:

DP>Эта фраза указывет на то, что проблема, скорее всего, в руководителе. Заказчики, значит, компании доверяют, а ее руководитель своим подчиненным — нет. Хотя руководитель должен быть буфером между заказчиком и подчиненными, организовать эффективную и комфортную работу, брать на себя общение с заказчиками и удовлетворение их хотелок знать точные часы.
Интересно, как это руководитель может знать точные часы, если сами подчиненные их не знают?

И то же самое можно сказать про доверие.
Очень хочется доверять подчиненным.
Но если на вопрос "сколько это у тебя заняло времени, чтобы выставить заказчику",
подчиненный отвечает: "ну напишите часов 3-5", как можно доверять?

Здравствуйте, DiPaolo, Вы писали:

DP>А если человек обдумаывет решение задачи во время обеда, в туалете или когда пьет чай? Как это учитывать?
Про это уже много раз спрашивали и я много раз отвечал.
Пришел на рабочее место и так и запиши: "14-15 — 14-45. думал над решением задачи, решил сделать пузырьковую сортировку для...."

DP>PS вообще, стоит задуматься об организации рабочего процесса. Со стороны это выглядит странным, по крайней мере для работы программистов.
Какое другое решение?

Здравствуйте, DiPaolo, Вы писали:

DP>Я использовал Programmer's notepad. Надоело через пару недель. Но мне надо было для себя — понять, куда тратится время и повысить эффективность.
так это же просто текстовый редактор?

Здравствуйте, es3000, Вы писали:

E>Ну какой смысл будет в следующей информации:
E>- 1-й специалист решил вопрос за 2 часа
E>- 2-й специалист решил подобный вопрос за 5 часов?

Смысл для кого — для Вас или для заказчика? Если для Вас, то, согласен, Вы можете подумать над тем, как улучшить технологию решения подобных задач. Если же для заказчика, то его вообще не волнуют ни 2, ни 5 часов. Предположим, нормативное время решения данной задачи составляет 4 часа — вот заказчик и оплачивает 4 часа, а не 2 или 5.

E>Главная цель отчетов — для заказчика.

Зачем заказчику "измельчённые" задачи, из которых он вряд ли может составить реальную картину происходящего. Его должны интересовать задачи не слишком крупные и не слишком дробные и нормативное время их выполнения, по которому он и платит.

Здравствуйте, es3000, Вы писали:

E>Здравствуйте, bkat, Вы писали:

E>>>И эта же задача поступает программисту (вернее не программисту, а специалисту поддержки), то есть она не детализируется, она в исходном виде поступает специалисту.
E>>>Поэтому специалист сам ее должен детализировать

B>>Отлично.
B>>И что вы делаете с тем, что специалист напланировал?
B>>Заносите в JIRA или подобное?
B>>Этого не достаточно?

E>Сейчас ничего.
E>Я имел ввиду, что специалисту поступает задача, она заносится в систему типа Jira, но без детализаций.
E>Дальше от него требуется выполнить эту задачу, поставить отметку о выполнении и трудозатратах.

E>То, что я сказал "специалист сам ее должен детализировать" — это я имел ввиду, что он сам для себя умственно продумывает способ решения.
E>То есть сейчас эту "умственную детализацию" мы никуда не пишем.

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

Только не переусердствуйте с детализацией планов.
Предвижу наезды на девелоперов, типа не могут спланировать на уровне чихов...

Здравствуйте, bkat, Вы писали:

B>Ну если у вас нету плана в явном виде на этом уровне, то как вы вообще можете тогда требовать отчетов?
B>Без явных планов не будет и отчетов.
B>Отчеты по явным планам пишутся довольно легко.
B>Как только пройдете и осознаете этот этап, сразу поймете что никаких дополнительных тулов вам не нужно.

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

Если этот вопрос сам специалист не может решить и требуется вмешательство разработчиков — тогда работает другая цепочка.
Мы ее сейчас не рассматриваем.

Здравствуйте, Кирилл Лебедев, Вы писали:

E>>Ну какой смысл будет в следующей информации:
E>>- 1-й специалист решил вопрос за 2 часа
E>>- 2-й специалист решил подобный вопрос за 5 часов?

КЛ>Смысл для кого — для Вас или для заказчика? Если для Вас, то, согласен, Вы можете подумать над тем, как улучшить технологию решения подобных задач. Если же для заказчика, то его вообще не волнуют ни 2, ни 5 часов. Предположим, нормативное время решения данной задачи составляет 4 часа — вот заказчик и оплачивает 4 часа, а не 2 или 5.
Я имел ввиду смысл для нас.
Как правильно вы сказали: чтобы подумать над тем как улучшить технологию решения.
И чтобы правильно вычислить нормативное время.

E>>Главная цель отчетов — для заказчика.
КЛ>Зачем заказчику "измельчённые" задачи, из которых он вряд ли может составить реальную картину происходящего. Его должны интересовать задачи не слишком крупные и не слишком дробные и нормативное время их выполнения, по которому он и платит.
Тут я неточно выразился.
Главная цель отчетов — посчитать справедливые (для обеих сторон) трудозатраты, выставляемые заказчику.

Здравствуйте, es3000, Вы писали:

E>Я имел ввиду смысл для нас.
E>Как правильно вы сказали: чтобы подумать над тем как улучшить технологию решения.

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

E>Главная цель отчетов — посчитать справедливые (для обеих сторон) трудозатраты, выставляемые заказчику.

Справедливость бывает только при коммунизме, а у Вас с заказчиком — договорняк.

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

Вячеслав Педак

Здравствуйте, es3000, Вы писали:

V>>Реально обычно это делается примерно. Есть оценка задачи, заказчик ее видит и согласен, работник ее делает в срок и заказчику выставляется счет на все это время.
V>>Нафига мудрить? Заказчик захотел что-то, оценка его устраивала, он получил. Что еще надо?
E>Я много раз уже и выше и ниже описывал: нету у нас предварительных оценок по этим работам.
E>И заказчик платит платит факту.

Здравствуйте, es3000, Вы писали:

E>Тараканы не у руководителя, а у заказчиков, которые платят по часам.
Всю жизнь думал, что заказчики платят за решение их проблем. Оказалось, за жопочасы...

E>А наше руководство и я в том числе, заинтересовано в том, чтобы и специалисты и заказчики были довольны друг другом.
Т.е. вы банально посредники или другими словами — фриланс-биржа.

Здравствуйте, es3000, Вы писали:

E>Но если на вопрос "сколько это у тебя заняло времени, чтобы выставить заказчику",
E>подчиненный отвечает: "ну напишите часов 3-5", как можно доверять?
Попробуйте не формулировать вопросы подобным образом.
Такая постановка вопроса — попытка переложить на подчиненного ответственность за выставление
ценника заказчику. Это не вопрос о том, сколько он потратил времени, а какой ценник выставить
заказчику.

Допустим, подчиненный затратил на это 15 минут, но он знает, что реальная ценность проблемы
для заказчика — как раз часа 3-5. Он подсознательно заинтересован в успехе фирмы (да и значимость
свою хочет подчеркнуть) и дает реальную ценность.

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

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

Здравствуйте, _ABC_,

_AB>Если он на сдельной работе,
_AB>то это нормально — он по сути для вас субконтрактор и функции менеджмента лежат полностью на нём
_AB>самом. Но если разработчик на фиксе, то отслеживание его производительности и загруженности — ваша
_AB>(менеджмента) задача.

Нет, вот это утверждение неверно.
Если разработчик — наемный служащий, то не имеет значения, на сдельной ли он работе или на фиксе. В любом случае, отслеживание производительности и загруженности наемного служащего — это задача менеджмента. За это упомянутый менеджмент и зарплату получает. А вот если разработчик — независимый субконтрактор, тогда да, все функции менеджмента на нем. Но здесь ключевое слово "независимый", и отношения строятся совершенно иначе, чем с наемным служащим.

On 25.02.2015 15:48, vpedak wrote:

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

А убытки фирмы покрывать менеджер будет или разработчик ) ?

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

И, кстати, не знаю как jira, а в redmine учёт отдельных деятельностей в
ходе задачи вполне реализован.
--
WBR,
Serge.

Здравствуйте, Vlad_SP, Вы писали:

V_S>Нет, вот это утверждение неверно.
V_S>Если разработчик — наемный служащий, то не имеет значения, на сдельной ли он работе или на фиксе. В любом случае, отслеживание производительности и загруженности наемного служащего — это задача менеджмента. За это упомянутый менеджмент и зарплату получает. А вот если разработчик — независимый субконтрактор, тогда да, все функции менеджмента на нем. Но здесь ключевое слово "независимый", и отношения строятся совершенно иначе, чем с наемным служащим.

стоимость... зависимый-независимый... дело не в этом.

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

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