От инженера до руководителя. Часть 3: Отчёты / Хабрахабр. Отчёты — отличная вещь. Они позволяют защищать как заказчика, начальника, так и сотрудника со всем проектом.

Они позволяют ими управлять и оценивать их. Вы же, в конце концов пишете код не с усердием дрессированной обезьяны тысячи раз переписывая патерн visitor, а вначале всё- таки сидите и думаете, рисуете на бумажке, планируете код и тесты (я верю в вас!)? Но с другой стороны, отчёты — вещь контроля и организации, которая всех отвлекает от непосредственной работы. И всё равно, в том или ином роде на работе нам приходиться с ними сталкиваться.

Это был так называемый weekly report, в котором полагалось писать то, что ты. Каждый инженер в конце своего рабочего дня тратит 5 минут времени для того, чтобы написать ежедневный отчёт и отправить его на . Как написать отчет по практике: правила и примеры. Тут же дается оценка собственной работе, и адекватно оцениваются . ОТЧЕТ О ПРОДЕЛАННОЙ РАБОТЕ. УПРАВЛЕНИЯ СТРАТЕГИЧЕСКОГО РАЗВИТИЯ. АДМИНИСТРАЦИИ КЕМЕРОВСКОЙ ОБЛАСТИ. ОТЧЕТ о проделанной работе за 2010 год. ООО «УК «Уютный дом». Основными задачами в работе компании являются: качественное уп- равление.

Зачем и как искать компромисс? Добро пожаловать под кат всем, кому интересно моё мнение по этому вопросу и тем, кто читал мои предыдущие статьи: От инженера до руководителя.

О РАБОТЕ УПРАВЛЕНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Основные цели и задачи Управления ИТ. Функциональным назначением . Иногда бывает труднее отчитаться о проделанной работе, чем выполнить ее. А между тем, от такого отчета может зависеть очень многое. Источники: отчет о выполненной работе образец . Но с другой стороны, отчёты — вещь контроля и организации, которая всех отвлекает. Найти инженера-геолога в Москве - 3764 резюме с заработной платой до. Геолог, Телефонист, Техник-геолог 1 категории, Менеджер по работе с .

Часть 1: Чувство справедливости. От инженера до руководителя.

Часть 2: Делегирование и постановка задачи. Overflow. Все премудрости баланса и гармонии я познал не смотря на сакуру и проплывающие трупы своих начальников, а в суровой реальности. И реальность была и вправду сурова. В тёмные времена прислали нам тёмного менеджера из далёкой Африки. У него была великолепная белая улыбка, которую ночью в тёмном переулке можно было спутать с улыбкой исчезающего Чеширского Кота, но совсем немного было представления о том, что такое самолёт, который, мы, в общем- то и делали.

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

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

Поэтому список заданий накапливался людьми в локальных файликах, а затем переносился в строчки таблицы с указанием подотчётного. Инструкция Сигнализации Aps 1350. За время, когда освобождался файл бились и сражались. И если кому не повезло дождаться освобождения файла, он оставался и во вне рабочее время, чтобы занести в табличку разноцветные статусы.

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

И на одном из митингов он понял, что у людей случаются проблемы. И их тоже надо заносить в таблицу: найденный баг, проблемы у человека с запуском на симуляторе, отсутствие модуля и пр., впрочем, без проблем с смой таблицей. Так появилась второй файлик и таблица, в которую надо было заносить баги, с переносом всех проверенных статусов из первой. Однако, как выяснилось спустя неделю, что это не столь эффективно, и надо всё- таки что- то подсчитывать, а подсчитывать и пересчитывать сотни изменений менеджер не успевал. Поэтому он пришёл как- то утром и с улыбкой чеширского кота, промурлыкав: “Hi guys, how are you, guys?”; предложил заполнять и третью, в которой результатами были бы числа, посчитанных вручную результатов и их проценты же, потому что таблицы для безопасности менеджер залочил. Причём, дополнялось, чтобы была обратная связь с первой — заполнять прогресс там, что если что- то не успевалось, то указывать статус на модуль “задержан”, а во вторую вносить правку — проблемы со временем.

Надо ли говорить, что проблемы со временем появились задолго до этих нововведений? Чертеж Формы Пеноблок далее. По сути в каждой из команд один из её участников только и занимался заполнением этих таблиц, безбожно путая и пропуская то, что было в куче текстовых файлов. А так как файлы таблиц ломались из- за того, что в них оказывались ошибки, для сохранения статистики их сохраняли все (каждую под отдельным именем), после критического изменения, и они размножались как на дрожжах, и понять, какая же последняя и актуальная — было проблематично. Проект закрыли в срок. Менеджер ушёл по собственному желанию за неделю до закрытия проекта и укатил на своём аистёнке в голубую даль, оставив нам суровые будни и чёрные размышления.

Которые были следующими: отчёты это хорошо, но они должны занимать минимум времени. Особенно в IT- сфере. Это должно делаться в один клик, а остальное считать и делать должны программы, причём отчёты и их составление не должно мешать работать другим людям. В идеале — это клик по чекбоксу\ползунку на прогресс баре с фидбеком в багтрекинговой системе при необходимости.

Не всегда это возможно, и приходится выкручиваться невообразимыми костылями при отсутствии централизованной практики, но упрощать затраты на отчётность и доверять технике, а так же иметь представление о предметной области надо в первую очередь. Чтобы, как минимум, не отвлекать специалистов от работы. Underflow. Помимо доверия к технике вычислительной, надо руководствоваться и техникой понимания людей. Наученный примером менеджера, в одном из последующих проектов я подготавливал ежедневные отчёты, в которых помимо перечисления всего, что было сделано за день, сравнивалось с запланированным автоматически, достаточно было поставить только pass\fail напротив актуальной задачи. И в начале новой недели я хотел отчитаться, что закончил работу вдвое быстрее. Красивые графики для менеджеров «запланировано» и «сделано» оптимистично расходились и поднимусь ввысь. Отчёты проходили через тим лида, прогресс есть: видно когда и что сделано.

Да вот еженедельный брифинг у руководителя проекта оказался поводом вызвать меня и задать вопрос: “Ты чего растягиваешь сроки? Мы зачем тебя тут держим?”. Оправдания о том, что работа будет сделана завтра, мало кого интересовала, т. Я остановился и подумал, что же тут не так.

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

Квинтэссенцией моего опыта составления отчётов было составление дорожной карты одного из проектов. Division by zero. Дорожная карта представляла собой список всех модулей, над которыми предстояло работать. В ней надо лишь было проставить статус задачи. Пара минут в день. Всё остальное система делала сама.

Подсчитывала, кто и сколько чего сделал, когда, какой прогресс, какие тенденции, какие проблемы, какой план, какой скорректированный план, эффективность и прочая. Единственное, что надо было сделать члену команды — щёлкнуть по своему модулю и поставить pass\fail, и затем можно было сгенерировать отчёт для руководителя со всем необходимым, чтобы последнему осталось лишь передвинуть прогресс в MS Project, и при необходимости внести те поправки, которые он посчитает нужным. Проект оказался не тривиальным, за место обычной верификации и допиливания, приходилось изучать электрические схемы, считать напряжения, силу тока, смотреть последствия разрыва\замыкания цепей и переносить их логику и их влияние на код.