Как программисту вести отчётность для руководства?
После очередной беседы с руководством возник вопрос в ведении отчётности и планировании работы.
При этом, руководитель, конечно же, ничего не понимает в программировании, а мне лень писать ежедневные/еженедельные отчёты о состоянии дел.
В компании, где я работаю, есть всего два web-разработчика и немалое количество проектов, которые надо либо переделывать полностью, либо поддерживать их и исправлять огромное количество багов (пока до них не дойдёт очередь полного обновления).
В силу того, что мы ребята молодые и опыта в ведении отчётности и планировании работы нет, то возник вопрос, как лучше вести отчётность для тех людей, которые не понимают ничего в программировании, но при этом, имеют возможность при необходимости показать своим друзьям-программистам и спросить совета "а чем эти парни занимаются у меня в компании?".
Собственно, вопрос: посоветуйте, какие средства/программы/решения/блокноты/кульбиты/фокусы использовать, чтобы нам было легко и просто жить, и при этом вести отчётность ежедневно или еженедельно?
Есть такая волшебная вещь - Trello. По сути это доска задач со стикерами только в электронном виде. Для небольших команд самое то. Отчёты можно выгружать в json или excel, либо просто дать доступ начальству к доскам проектов чтобы оно видело статус работ в реальном времени.
Если Trello приживётся, то потом можно перейти на Jira или redmine.
Все эти сервисы позволяют вести проекты, указывать задачи, подзадачи, что сделано что не сделано, вести переписку по каждой задаче, комментировать, учитывать время, показывать отчеты и графики.
От себя могу поведать так.
Как ПМ могу ответить, что перед постановкой задач на разработку я составляю список фич.
Разбиваю проект на модули или компоненты и каждый модуль набиваю фичами.
Выглядит это примерно так:
Пользователи:
Создание пользователя
Удаление пользователя
Деактивация пользователя
И так на каждый модуль. В итоге в зависимости от проекта собирается от 50 до 200 фич.
Свои отчеты так и собираю, только фичи мне известны. А собираю в основном часы. Каждая фича у меня оценивается перед началом разработки и я имею эталонное время. Добавив к которому риски и корреляцию на опыт, могу увидеть время необходимое на разработку модуля или отдельно взятой фичи. Соотв. отчетность собираю по трудозатратам на фичу-модуль.
Попробуй составлять отчет в виде какая фича переделывалась или делалась с нуля и сколько было затрачено на это времени.
Вы о чем??? Каким боком Скрам подойдет группе из двух человек с целями типа "от забора и до обеда"?.. если у них не то, что Продуктовнера нет, но руководство даже не знает, какие хочет отчеты? Если тут вообще уместно слово подойдет, то тогда уж Канбан. А по хорошему - бежать нужно из этой богодельни :(
@pi314 Ребята не знают как планировать задачи, а также как предоставлять отчетность руководству. Кто-то ведь задачи им ставит, кто-то проверяет, они же не сами по себе работают. Пусть в группе мало человек, но один человек может совмещать несколько ролей. А руководитель компании пусть выполняет роль внутреннего заказчика.
@pi314 Конечно это при условии, что ребята хотят улучшить ситуацию и проявить инициативу (можно объяснить руководство, что это нормальный подход), а так, безусловно, такими вещами руководство должно заниматься, а если ему до лампочки, то бежать надо из такой компании.
@Fandorin Дело в том, что Скрам для групп меньше 5-7 человек полезен, как рыбе зонтик. Для всяких совмещений ролей, процентного участия (на проекте полтора программиста) и прочего креатива, неизбежного в ситуациях, когда для внедрения Скрам нет необходимых предпосылок, существует даже специальный термин "как бы-скрам" (ScrumBut) именно от того, что все это прямо противоречит сути методики. Насколько я понял, проблема не в том, что не знают, КАК планировать, а в том, что никто не берет на себя отвественность сформулировать ЧТО должно быть сделано и каковы приоритеты. Один не разбирается, другому лень (ибо, вероятнее всего, это не оплачивается), а третий (знакомые программисты) все равно не в теме и ни за что не отвечают.
Это очень распространенная ситуация, когда руководство "доверяет" планирование подчиненным. В переводе на человеческий язык это означает "дай мне план, из которого я наконец узнаю, что я от тебя хочу". Ситуация принципиально шизофреническая, и упомянутые консультации со знакомыми программистами гармонично дополняют клиническую картину, означая "я дам этот план на проверку кому-то другому, чтоб узнать, правильно ли это". Классический подход не менеджера, но функционера!
Если руководитель реально хочет чего-то, в чем не разбирается, он найдет того, кто разбирается и чьей компетентности он доверяет, и назначит его планировать, ставить задачи и т.д. и будет с него спрашивать отчеты, и вопрос формы этих отчетов прояснится сам собой. Если этого не происходит, значит никому ничего на самом деле не нужно и незачем огород городить.
@pi314 вы неправильно поняли ситуацию. У нас есть приоритеты и мы (те самые два рограммиста) их понимаем, у нас есть проекты и нам нравится их развивать и мы понимаем, что мы хотим, но у нас нет никакой документации/планов/гайдов и мы просто не делаем никаких прототипов, а сразу кодим. Именно от этого я хочу отойти и начать строить эффективную команду. Да, можно было бы пойти работать в крупную компанию и там научиться всему и только потом идти к тому человеку, который тебе доверяет (а мне мой руководитель доверяет в плане работы, просто ему хочется понимать, за что всё таки он мне платит, потому что условия работы у нас немного лояльные - об этом отдельно ниже) и который готов платить тебе зарплату за то, что тебе нравится и чем ты хочешь заниматься. Но вот так сложилась ситуация, что мой работодатель готов платить мне деньги за то, что я 2 дня в неделю работаю удалённо + 3 дня из офиса, за то, что я могу курить любимый кальян в офисе в любое время и мне ничего за это не будет, главное работу свою делать. Но вот проблема с планированием. Мы не умеем этого делать. Соответственно мы не умеем отчитываться за то, что сделали, потому что в моём понимании это взаимосвязанные вещи. Мы сказали. что сделаем этот сайт за две недели, но когда начали делать оказалось, что не всё так просто. Он нам по силам, но времени намного больше, потому что хочется запилить много плюшек, которые по ходу работы только выплывают. Я понимаю, что это грабли и хочу просто побыстрее через них пройти, чтобы и опыт стал полезным и выработалась удобная нам система функционирования команды. Вопрос только в том, какими ресурсами это устроить.
Нужно было видеть кто, сколько и на какую задачу потратил время. Менеджер, далекий от программирования, смотрел сколько времени тратилось на задачу и выставлял стоимость работ. Так же к задаче оставлялись комментарии с пояснениями и реализованными фичами, возникшими проблемами и прочее. У задач можно указать критичность и временные рамки. Наш менеджер смотрел, какую задачу делает программист, если критичность высокая или время поджимает, то он программиста не тревожил и ему новый важные задачи не ставил. У битрикса конечно есть нюансы, но попробовать стоит.
А как объяснить саму суть задачи? Вот написал я часть функции в класс, несколько раз еще его поправил и тд.. Не будешь же указывать какие переменные определил, как и в каком количестве. Понятно, что я смогу объяснить, что это все делает, но не смогу объяснить трудоемкость работы. Классы разные бывают
Если важно не кто сколько работал, а что сделал, то делайте более менее осмысленные коммиты и описания к ним, кому надо откроет код посмотреть, кому не надо так почитает, об успехах и фиксах.
Выделите кто будет лидом. Поставьте Bugzilla или Jira. Лид будет заниматься частично менеджментом тасков и багов. Митинги о состоянии дел, 15минут в день хватит. Заведите Wiki, почту общую.
Простой
