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

Спасибо за ценное руководство к действию.
Попробуем освоить redmine.

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

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

E>>И мы так хотим сделать. Чтобы было удобно и никого не напрягало.
E>>Какой у вас был инструмент?
_>Сами писали.
А из существующего что порекомендуешь?

_>Тут есть одно, такая система работает только там, где все остальное хорошо. И он не является определяющей, т.е. для менеджмента эта система подобие лакмусовой бумажки
Согласен.
Мы работаем над тем, чтоб все было хорошо.

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

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

Конечно есть какой-то разумный предел: не стоит описывать каждую минуту затраченного времени.
А выход какой ты предлагаешь?
вообще не учитывать что и сколько делал человек?

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

E>Нам нужно облегчить эту работу для программистов, предоставить им какое-нибудь ПО для этого.

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

Для разборок отчеты вообще бесполезны.
Если считаете что человек слишком медленно работает, то лучше просто увольняйте, чем демотивировать разборками.
Производительность программистов может запросто отличаться на порядок.
Либо вы учитесь с этим жить, либо вам не место в реальных проектах с реальными людьми.
Какой смысл в том, что "крутой" будет разбираться с "середняком"?
Смысла нету... Есть смысл помочь, но для этого отчеты совсем не нужны.
Короче учитесь работать с людьми, а не надеятся на формалистику...

А вообще курите тот же скрам к примеру.
Я не совсем не фанат скрама, но методики оценок и предсказаний у них вполне рабочие.

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

E>А выход какой ты предлагаешь?

я предлагаю две вещи
1) не мешать программистам делать свою работу
2) Вам сменить профессию, чтобы больше не наносить ущерб моей отрасли.

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

A>я предлагаю две вещи
A>1) не мешать программистам делать свою работу
A>2) Вам сменить профессию, чтобы больше не наносить ущерб моей отрасли.

1) речь идет не только о программистах, есть еще специалисты поддержки
2) какую же такую загадочную работу делают программисты, что не могут о ней ничего сказать и отчитаться?
3) а у нас полно случаев когда сам программист наносит ущерб и себе и компании и заказчику, когда не имея достаточной самодисциплины, не может точно вспомнить:
— во сколько начал работать
— во сколько закончил
— куда и на что его отвлекали за это время
— и как результат почему решение обычного вопроса на 2 часа у него затянулось на 2 дня


Просто ты витаешь в облаках, в идеализированных облаках

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

B>Облегчить работу программистам в этом случае можно только если
B>учет времени делать на том же уровне, что и выдаваемые им задачи.
Ну какой смысл будет в следующей информации:
— 1-й специалист решил вопрос за 2 часа
— 2-й специалист решил подобный вопрос за 5 часов?
Из этого не понять в чем разница между двумя этими вопросами.
И приходится гадать: то ли 2-й специалист хуже, то ли его отвлекали на другие вопросы, то ли у него понос внезапно случился, то ли еще что-то...

Поэтому учет нужно вести на 1 уровень глубже чем выдаваемые задания.
Когда мы будем иметь детализацию на 1 уровень ниже — это все объяснит: будет точная и ясная картина решения задачи.

B>Вы же не даете им задачи на уровне каждого чиха, отдельных методов и строчек файла?
Нет, не нужно на каждый чих и отдельных строчек кода.
Пример, который я привел — может быть не совсем правильный.

B>Для разборок отчеты вообще бесполезны.
B>Если считаете что человек слишком медленно работает, то лучше просто увольняйте, чем демотивировать разборками.
Я уже много раз писал, главная цель — это не для разборок.
Главная цель отчетов — для заказчика.

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

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

E>Поэтому учет нужно вести на 1 уровень глубже чем выдаваемые задания.
E>Когда мы будем иметь детализацию на 1 уровень ниже — это все объяснит: будет точная и ясная картина решения задачи.

Ну ты еще учти, что как только эта самая "детализация на 1 уровень ниже" начнет мешать собственно решению задачи — программисты начнут ее обходить и обманывать. Нет, по отчетам у тебя будет все "шоколадно"! И придраться ты ни к чему не сможешь. Вот только с реальностью вся эта шоколадность будет соотноситься очень и очень отдаленно....

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

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

E>Поэтому учет нужно вести на 1 уровень глубже чем выдаваемые задания.
E>Когда мы будем иметь детализацию на 1 уровень ниже — это все объяснит: будет точная и ясная картина решения задачи.

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

B>>Вы же не даете им задачи на уровне каждого чиха, отдельных методов и строчек файла?
E>Нет, не нужно на каждый чих и отдельных строчек кода.
E>Пример, который я привел — может быть не совсем правильный.

B>>Для разборок отчеты вообще бесполезны.
B>>Если считаете что человек слишком медленно работает, то лучше просто увольняйте, чем демотивировать разборками.
E>Я уже много раз писал, главная цель — это не для разборок.
E>Главная цель отчетов — для заказчика.

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

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


E>не понял твою мысль, поясни

он предлагает ещё посекундно считать + учитывать расход кислорода разработчиками в процессе
а также выбросы и загрязннеие окрсреды. я с ним согласен. уж оченъ гуманны вы, не учитываете ещё
много факторов

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

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

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

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

B>В стандартных ситуациях это не нужно. А для разборок достаточно просто говорить с людьми.
B>Зачем вам усложнять стандартный случай?
Повторяю в 101-й раз: этот учет нужен не для разборок.
Этот учет нужен для справедливого выставления счетов заказчику.

B>Заказчику ваши цифирки тем более не нужны.
Согласен.
И все-таки несколько лет работы было несколько раз когда заказчики попросили подробности.
И если бы у нас этих подробностей не было, мы бы не смогли убедить заказчика, что указанные трудозатраты — реальные.

B>Заказчику достаточно затраты в часах в целом на уровне задач, которые он ставит, которые он и оплачивает.
B>Если он считает, что вы слишком дороги (малый выхлоп за потраченные часы/деньги), то врядли он захочет разбираться с вашими цифирками.
Как я выше написал: такие ситуации были.
Только вопрос был не в том, что мы дороги, а в том почему за конкретный
период получилась большая сумма. На что ему были предоставлены подробные отчеты за этот период.
После этого вопросы у заказчика отпали.

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

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

...

Ещё один иннициативный манагер хочет этих лентяев программеров научить работать Откуда вы только берётесь?

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

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

B>>Облегчить работу программистам в этом случае можно только если
B>>учет времени делать на том же уровне, что и выдаваемые им задачи.
E>Ну какой смысл будет в следующей информации:
E>- 1-й специалист решил вопрос за 2 часа
E>- 2-й специалист решил подобный вопрос за 5 часов?
E>Из этого не понять в чем разница между двумя этими вопросами.
E>И приходится гадать: то ли 2-й специалист хуже, то ли его отвлекали на другие вопросы, то ли у него понос внезапно случился, то ли еще что-то...

Была уже тема с подобными рассуждениями. Из него вынес ключевое слово — специалист. Посмотрите на изображение, программисты видят менеджера проекта лентяем с ногами на столе. Менеджер же представляет программистов одинаковыми как клоны работниками.

	Скрытый текст

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

0    не знает
20    плохо
40    неудовлетворительно
60    удовлетворительно
80    хорошо
100    отлично

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

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

специализация | Вася Пупкин | Иванов Иван | …

C++
-парадигма программирования
--процедурное программирование
--функциональное программирование
--объектно-ориентированное программирование
--обобщенное программирование
IEC 61131-3
-Instruction List (IL)
-Ladder Diagram (LD)
-Function Block Diagram (FBD)
-Sequential Function Chart (CFC)
-Structured Text (ST)
Qt
-основные модули Qt
--QtCore
--QtGui
--QtMultimedia
--QtNetwork
--QtOpenGL
--QtOpenVG
--QtScript
--QtScriptTools
--QtSql
--QtSvg
--QtWebKit
--QtXml
--QtXmlPatterns
--QtDeclarative
--Phonon
Базы данных
-Sqlite
-Postgres
-MySQL
-MSSQL
-MS Access

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

Но вот что интересно, иногда пункты начинают пересекаться. Банально:

C++=>-парадигма программирования=>--процедурное программирование
IEC 61131-3=>-Structured Text (ST)

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

Или вот поручают человеку написать, что-то на:

C++=>-парадигма программирования=>--обобщенное программирование 20%
boost=>-boost.asio 10%
протоколы обмена данными=>сетевые=>tcp/ip 40%

А у него специализация:

C++=>объектно-ориентированное программирование 80%
Qt=>-основные модули Qt=>--QtNetwork 60%
протоколы обмена данными=>сетевые=>tcp/ip 40%

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

Если человек не справился, а по таблице специализации должен бы, значит ему можно понизить уровень его специализации. Но нужно понимать, что все эти метрики действуют только с чётко поставленной задачей, когда программисту изначально ясно, как он будет её выполнять. Если задача не ясна, аля «Поди туда — не знаю куда, принеси то — не знаю что», тогда такой метод оценки не сработает. Более того, скорее всего будет выбран неправильный исполнитель.

И понятно, что история успеха управления такой компанией как IBM совершенно не подойдёт небольшой фирме. Бюрократия обычно растёт с ростом компании, так как с одной стороны мешает, а с другой без неё никакой дальнейший рост попросту невозможен. А для того, чтобы понять нужны конкретные инструменты или нет, их иногда приходится пробовать. Постоянно на форумах пишут противоречивые отзывы, что дескать «Я пробовал XXX и мне понравилось», или про тоже самое «Хуже XXX ничего в жизни не встречал, люди не используйте XXX, поберегите свои нервы!!!».

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

E>Так выход какой из этой ситуации?
E>Нужно выставить счета, как узнать какие трудозатраты писать в эти счета, если мы учет не вели?

Если всё в программистах устраивает и дело не в эффективности, а только в каких-то счетах, тогда зачем всё это. Некоторые заказчики хотят поиметь всё по бросовым ценам, и старательно ищут дурачков, а потом найдя дрючат их, и не заплатив уходят, ведь это же дорого. То есть, если в магазине хлеб стоил 30 рублей, на заводе 10 рублей, а у заказчика нет денег, и он идёт к вам, и говорит, ну Вася, нужен мне хлеб. Вы ему его делаете, а он отвечает, что-то дорогой у вас хлеб, я рассчитывал на 1 рубль, а он 5 рублей. Нет, оставьте себе, поищу по 30 копеек. Все хотят получить за дёшево, и такой софт есть, но не заказной, а с лицензией на один компьютер. Заказной софт никогда не будет столь же предсказуем в цене, как уже созданный тиражируемый продукт.

E>Вопрос не в доверии, мы доверяем своим программистам!
E>Разбор полетов — тут не причем, мы не собираемся разбирать полеты по этим записям, не это главное.

К чему тогда такие подробные записи? Особенно про "думал, когда катался на лыжах".

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

V>Если всё в программистах устраивает и дело не в эффективности, а только в каких-то счетах, тогда зачем всё это. Некоторые заказчики хотят поиметь всё по бросовым ценам, и старательно ищут дурачков, а потом найдя дрючат их, и не заплатив уходят, ведь это же дорого. То есть, если в магазине хлеб стоил 30 рублей, на заводе 10 рублей, а у заказчика нет денег, и он идёт к вам, и говорит, ну Вася, нужен мне хлеб. Вы ему его делаете, а он отвечает, что-то дорогой у вас хлеб, я рассчитывал на 1 рубль, а он 5 рублей. Нет, оставьте себе, поищу по 30 копеек. Все хотят получить за дёшево, и такой софт есть, но не заказной, а с лицензией на один компьютер. Заказной софт никогда не будет столь же предсказуем в цене, как уже созданный тиражируемый продукт.

Ты не отвечаешь на вопрос.
У нас нормальные заказчики, нормальные программисты.
Оплата идет за реально выполненную работу.

Так вот как определить какая работа и сколько этой работы было реально выполнено, если учет не ведется?

Как ни крути, другого выхода нет — надо вести учет.

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

SD>К чему тогда такие подробные записи? Особенно про "думал, когда катался на лыжах".

р-р-р-р-р-р....!!!!

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

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

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

B>>>Облегчить работу программистам в этом случае можно только если
B>>>учет времени делать на том же уровне, что и выдаваемые им задачи.
E>>Ну какой смысл будет в следующей информации:
E>>- 1-й специалист решил вопрос за 2 часа
E>>- 2-й специалист решил подобный вопрос за 5 часов?
E>>Из этого не понять в чем разница между двумя этими вопросами.
E>>И приходится гадать: то ли 2-й специалист хуже, то ли его отвлекали на другие вопросы, то ли у него понос внезапно случился, то ли еще что-то...

V>Была уже тема с подобными рассуждениями. Из него вынес ключевое слово — специалист. Посмотрите на изображение, программисты видят менеджера проекта лентяем с ногами на столе. Менеджер же представляет программистов одинаковыми как клоны работниками.

Много теории.

И все-таки, давай ближе к вопросу.

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

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

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

U>Ещё один иннициативный манагер хочет этих лентяев программеров научить работать Откуда вы только берётесь?

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

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