О работе и её эффективности

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

Слово "работа" может использоваться в качестве синонима слова "задача" ("сделал работу" == "решил задачу"), либо слова "результат" ("произведённая работа" == "полученный результат"), либо слова "занятость" ("сходил на работу" == "был занят 8 часов").

==== Адекватная производительность ===
Например, создание ветки в git-репозитории за 1 минуту - это адекватная производительность, а создание ветки за 6 часов - неадекватная. Если же человек 5 часов 50 минут расставлял отступы в коде, и только потом добрался создать ветку, это неэффективная работа, потому что время ушло на решение задачи, которая не была заявлена к решению.

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

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

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

====Оценка эффективности====
Чтобы помочь сотруднику оценивать эффективность своей работы, у нас создана система TIME@Etersoft. Она учитывает время, проведённое сотрудником за рабочим местом (занятость), а также запоминает и подсчитывает, время, потраченное на решение им конкретных задач (в bugzilla или RT). Развитие системы идёт, замечания и предложения принимаются.

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

==== Важность TIME@Etersoft ====
В связи с тем, что большинство сотрудников имеет плавающий график, вопрос учёта рабочего времени, как единственного общего для всех видом деятельности параметра, который можно замерить, имеет большое значение. Для сотрудников, работающих полный рабочий день, система TIME@ показывает, отработал ли человек положенное количество рабочих часов в день/неделю/месяц.
Система TIME@Etersoft позволяет увидеть задачи, которые поставлены к решению, а также их соотнесённость с задачами, которые решались в действительности, и сравнить время, проведённое на работе, с временем, затраченным на решение.

=== Необходимость в собранности ===
Как бы ни казалось это неудобным, блаженное время прошло. И мы больше не можем себе позволить работать над тем, что интересно и перспективно, но не имеет конкретной отдачи. Мы не можем себе позволить работать так, чтобы деятельность наша не приносила результата или имела низкую эффективность. Мы не можем себе позволить на благо других компаний или сторонних проектов. Не можем позволить широкой общественной деятельности. Поэтому нам нужны чёткие планы, конкретные сроки, к которым мы успеем выполнить работу, конкретные баги, которые необходимо решить.

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

=== Руководство к действию===
Есть простые правила. Для любой задачи должна быть бага. Просто не приступайте к работе, пока баги нет. Бага заводится либо тем, кто формулирует задачу, либо вами, если задача передана вам иным путём (по телефону, в джаббере, лично). Но фаза создания баги не должна пропадать. Именно по ней определяется, на что было потрачено ваше рабочее время. Обращайте внимание на приоритет багов, чтобы не решать второстепенную проблему при наличии горящей.

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

===Подведение итогов ===
Баги не должны закрываться через месяц с диагнозом "проработал 100 часов, всё сделал". Необходимо, чтобы при длинной задаче промежуточный итог (размышления, сегодняшние неудачи, предположения) заносились в багзиллу. Этим вы отметите, сколько времени проработали, а главное - дадите другим возможность ознакомиться с вашей работой и прокомментировать её.

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

=== Выпуск релизов ===
При составлении плана по релизам следует учитывать, что публиковать релизы нужно чаще (соответственно сам выпуск должен быть максимально автоматизирован и не вести к большим временнЫм затратам). Оптимально для нашей ситуации, когда релизы появляются 1-2 раза в месяц.

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

Это неоконченные тирады, посвящённые организации труда.