Re[7]: Система учета рабочего времени для исполнителя (прогр
От: velkin Удмуртия https://kisa.biz
Дата: 23.02.15 16:58
Оценка:
Здравствуйте, es3000, Вы писали:

E>За это (самочувствие и настроение) деньги не платят.

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

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

E>Но на самом деле разница может быть не только в этом.

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

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

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

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

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

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