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

E>Ты не отвечаешь на вопрос.

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

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

E> — 1 задача 2 часа + 1 задача 5 часов (и как в этом случае объяснить заказчику почему разница во времени решения этих двух задач, если даже мы сами этого не знаем)

Разница в наборах специализации, самочувствие и настроение разработчиков.

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


B>>Говорю вам как съевший на этом собаку.
B>>Не вы первый, кто работает на контрактах, оплачивающихся по часам.
E>Если вы съели на этом собаку — поделитесь опытом как вы ведете учет своих часов.
E>И бывают ли у заказчиков вопросы, когда вы выставляете эти часы?

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

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

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

B>Дак я тебе уже сказал.
B>Делаем учет на уровне задач, даваемых программисту.
B>Он уже более детален, с чем обычно имеет дело заказчик.

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

B>Ну а наезжать на девелоперов что они типа ленивые и не могут внятно сказать что они делают — это последнее дело...
B>Так вы с ними общего языка не найдете.

Никто ни на кого не наезжает.

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

E>> — 1 задача 2 часа + 1 задача 5 часов (и как в этом случае объяснить заказчику почему разница во времени решения этих двух задач, если даже мы сами этого не знаем)

V>Разница в наборах специализации, самочувствие и настроение разработчиков.

За это (самочувствие и настроение) деньги не платят.
Если у тебя плохое самочувствие или настроение — иди домой отдыхай, и не надо это писать в отчет.

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

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

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

B>>Дак я тебе уже сказал.
B>>Делаем учет на уровне задач, даваемых программисту.
B>>Он уже более детален, с чем обычно имеет дело заказчик.

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

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

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

E>За это (самочувствие и настроение) деньги не платят.
E>Если у тебя плохое самочувствие или настроение — иди домой отдыхай, и не надо это писать в отчет.

Если бы все программисты работали только бодрячком, то вполне возможно некого было бы нанять. Широко известная цифра, программист в сутки способен эффективно работать лишь 4 часа, и это замечу максимальный предел. Его превышение приводит к неэффективной работе для него прямо сейчас или в последующие дни. А это создаст на ваших временных замерах в коротких промежутках времени чудовищные несоответствия. У людей вообще очень много недостатков.

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

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

Специалист, специфика, специфичный. Лишь повторив одни и те же действия много раз обретаешь конкретные навыки. Проблема в том, что как только разработчик обретает навык, он ему уже может и не понадобится, так как программы могут работать и без него, а новые задачи меняются. Опять же если вернутся к заказчику, то посмотрите на системы управления проектами, сколько в них разнообразных графиков, диаграмм, всяких цифр и статусов. Более того, на каждую задачу идёт описание, все проводимые изменения, можно записывать мысли, общаться с другими разработчиками как на форуме.

В любом случае инструмент это всего лишь инструмент, к нему ещё нужны люди, которые умеют им пользоваться. Я как-то работал даже в таком месте, где ни один из разработчиков не вёл репозиторий и код никак нельзя было достать кроме как попросив его у других программистов. И руководству было на это наплевать, они наивные думали, что вот такое общение, в формате "Чё те надо" укрепляет дух команды, а не командные игроки им были не нужны.

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

С технической точки зрения это невероятно легко, что справится даже админ школьник. С организационной может оказаться невозможным. "Рыба гниёт с головы. Верхи не могут, низы не хотят." Ну пока кто-нибудь не отдаст команду ставить сервер, а потом в обязательном порядке обязать писать отчёты по каждой задаче, то сотрясать воздух можно сколько угодно. Тем кто их никогда не писал это окажется в новинку. Более того, всегда желательно иметь перед глазами реальный пример, чтобы хотя бы подражая научиться этому. И кто же окажется локомотивом прогресса?

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

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

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

B>Здравствуйте, es3000, Вы писали:
B>А вообще курите тот же скрам к примеру.
B>Я не совсем не фанат скрама, но методики оценок и предсказаний у них вполне рабочие.
Хотелось бы добавить что сркам неплохо работает, если есть хороший код, и команда не лепит задачи в код, а если надо обсуждает, проектирует и т.д.

E>Эти две системы как-то связаны друг с другом?
E>Например, если потом приходится сопровождать и дорабатывать в Итилиуме ту задачу, которая изначально разрабатывалась в Jira?
E>Есть ли связь между этими задачами, которые по сути связаны?

Здесь важно еще посмотреть структуру поддержки и разработки. У нас есть 2 варианта
1. В некоторых группах есть поддержка, которая занимается только сопровождением + есть отдельно группа, которая занимается только разработкой. Т.е сопровождение отдельно, разработка отдельно.
2. Есть поддержка, которая занимается в том числе и разработкой + есть группа, которая помогает им разрабатывать. Т.е. разработка — это сопровождение + люди которые ханимаются только кодингом.

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


E>А как программа точно называется?
Так и называется Итилиум. Это система на основе 1с. Была выбрана потому, что есть свои одинесники, которые могут в случае необходимости заниматься сопросовждением и мелкими допилками. Насколько я слышал — были сложности с внедрением "из коробки".

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

E>Наслышан про Redmine но сам не пользовался.
E>А есть что-нибудь десктопное?


"ManicTime", возможно, поможет.
Фиксирует на компе время активности всех приложений и ведёт базу с граф. отчётами.

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

E>Это можно на листике бумаги писать — листики теряются,
E>Кто-то в блокноте пишет, кто-то в Екселе, и т.д..
E>Короче, все подручные средства — это неудобно.
E>Надо что-то более комплексное.

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

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

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

E>Вопрос конкретный:
E>есть ли удобное ПО для этих целей?

MotivateClock можно глянуть.

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

E>Ну представь, ты решаешь задачу, отслеживаешь время, тут тебе позвонили по телефону по личному вопросу и ты проговорил 30 минут.
E>Затем снова начал работать, часа через 1,5 захотелось попить чай — пошел пить чай.
E>Потом пришел и еще за час задачу доделал.

E>Какие трудозатраты ты укажешь по задаче?
E>На калькуляторе складывать будешь?
E>трудозатраты = конец — начало — чай — телефон

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

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

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

E>Значит хреново у вас организовано было.
E>Вот мы и хотим организовать так, чтобы ни кого ни от чего не отвлекать.
E>На поддержке — выделенные сотрудники, они ни от чего не отвлекаются, взял вопрос — и доводит его до конца.
E>Они должны получить достойную з\п, но и заказчик не должен платить за "наобум"

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

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

E>Регулярно — никак. Они нам доверяют.
E>И вот чтобы это доверие не пропало, мы должны сами быть уверены, что наши сотрудники работают честно.

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

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

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

J>>в любой ситуации главное — задать правильный вопрос. всей темой тебе пытаемся показать, что вопрос у тебя неверный.
J>>универсального рецепта не существует, ни одна из софтин трекающих активность не решает задачу так как надо конкретному человеку.
E>ну хоть одну из софтин назовите наконец!
E>выше называли, но она на веб, лучше десктопную.

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

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

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

B>>Здравствуйте, es3000, Вы писали:
B>>А вообще курите тот же скрам к примеру.
B>>Я не совсем не фанат скрама, но методики оценок и предсказаний у них вполне рабочие.
_>Хотелось бы добавить что сркам неплохо работает, если есть хороший код, и команда не лепит задачи в код, а если надо обсуждает, проектирует и т.д.

Скрам — это по сути каша из топора.
Сам по себе он почти никакой ценности не представляет.
Но тот же planning poker — полезная практика.

А вред от скрама в том, что он дает манагерам иллюзию серебрянной пули.

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

V>А представь что пока я пил чай я думал над это задачей... Это как будем относить?
Нормально.
Так и пишем в отчет: думал над задачей 13-00 — 13-20.
Если ты действительно думал

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

V>А я еще и могу иногда параллельно две задачи сделать... Ну там фиксил одно, увидел, и закрыл и другое так как в одной области и похоже... Это как будем считать?
Да, часто работники перепрыгивают с одного на другое.
Наверно это не хорошо.
Лучше сначала доделать одну задачу, а потом заняться другой.

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

КЛ>Если не ошибаюсь, то в той же джире для задачи можно создать техническую подзадачу. Пусть разработчики создают подзадачи в рамках назначенной им задачи и трекают там время.

спасибо, попробуем этот вариант