С другой стороны – на листочках (ежедневниках, записных книжках) вести учёт всего ITшного производства – это просто измывательство над самими IT-специалистами (про всех не скажу, но я из оффлайновых писательных тулзов последнее время более-менее часто использую только краски-карандаши-гелевые ручки для зарисовок и рисунков), которые изрядно отвыкли от того, чтобы прописью, руками что-то писать, и это – в то время, когда клава под руками практически всегда. А конспектировать приходится обязательно. И когда от специалиста требуют какого-то периодического подведения итогов, тогда-то и становится явно видна великая польза от сих конспектов.

У нас, к примеру, принято ежегодное итоговое переинтервьюирование всех без исключения сотрудников (без малого год назад мы писали отчёты о 2006-м). С подведением итогов за прошедший период времени – чем занимался, в каких проектах в качестве кого участвовал, сколько времени какой проект занимал на фоне общей загрузки и как сам специалист (а после – его тим лидер) оценивает качество проведенной работы. И – даже за несколько месяцев (а уж тем более за год) вспомнить всё – задача не детская, и тем более при больших (и очень разных) нагрузках. Сортировка в файловой системе по дате тоже не сильно выручает, хотя и может являться опорной структурой для отчёта (да, конечно, каждый проект заводится в файловой системе в главной рубрике Projects, и в том случае, если это глобальный сервис с кучей подсайтов, и в том случае, если для проекта и надо-то было нарисовать один баннер или подредактировать чужое лого).

В офисе в течение последнего года все задания для разработчиков рулились через систему Jira, сие разработка от Atlassian. Не могу джиру оценить как оптимальный, универсальный продукт для управления задачами и распределения нагрузок команды разработчиков. Более чем часто сталкиваемся с тем, что как-то где-то не влазим в функциональность сервиса, чего-то не хватает, чего-то напротив, избыточно много. Но даже к несовершенству джиры приловчились (и умнички) – во всяком случае с отчётами, а так же с тем, кто сколько времени какому проекту уделял и даже насколько качественно – вот с подбивкой результатов проблем в этом году совсем не было.

Сама джира предполагает достаточно простую логическую структуру: можно заводить Проекты, в них – создавать задачи и подзадачи (task->subtask) . При этом Проекты – это как глобальный каталог реально разрабатываемых проектов, которые бывают очень крупные, не очень и совсем крошечные. Структурировать всё таким образом, чтобы этот каталог не разростался до безобразных-монстрообразных размеров, задача тоже не простая (возможность определять рубрики для проектов отсутствует, поэтому этот каталог одноуровневый, линейный). По этой причине на все типы мелкодизайнерских самодостаточных “проектиков” была создана одна еденица – Проект “Дизайн”, в котором уже задачами и подзадачами создавались задания на веб-сайты для группы дизайнеров. Не особо красиво, но так проще – а с точки зрения управления и контроля по большому счёту то же самое. При этом, если я ничего не путаю, создавать группы для Проектов нельзя только в нашей версии (у нас по традиции всё подешевле), в версии же “Enterprise” написано, что “Organise related projects into groups”, вот.

Каждому task`у можно прикреплять разработчика (дизайнера), предварительно заведенного в системе, можно назначать время, отведенное (по мнению постановщика задачи) на решение, дату начала работы, можно оставлять комментарии – в textarea расписать насколько угодно подробно что требуется, как требуется и где на что обращать внимание, можно прикреплять (при необходимости) любые документы, иллюстрации, любые файлы. Можно в рамках уже поставленной задачи создавать подзадачу (к примеру – задача “Интерфейс для программы ***”, подзадача – нарисовать картинки заданного размера в том же стиле на инсталлятор). Подзадаче (subtask) так же можно определять сроки, давать комментарии, назначать разработчика и прочее. Отправленная из системы задача приходит разработчику (которому назначена) на определённый в профайле мейл (дабы оперативно и не говорил потом, что “не заметил”). Если задача выполнена успешно – она разрешается (“Resolved”) как выполненная (“Done”). Так же у задачи могут быть и другие статусы – “Canceled”, “Won`t fix”, “Fixed”, “Duplicated”, “Incomplete”, “Cannot Reproduce”, статусы можно использовать для контроля над качеством выполнения тех же дизайнерских проектов – к примеру, какие эскизы были выполнены и одобрены заказчиком, какие — выполнены, но не одобрены и отменены, какие отправлялись на переделку, для подзадач (если возникали мелкие недоработки) — пофиксенные глюки. На самом деле очень удобно. Я всегда вижу — кто у меня сегодня чем занимается, кто на всей ветке задач занимается этим успешно, а кого лучше переключить на другие задачи, кто с какой скоростью работает (контролируемо, собирая статистику, а не держать в голове все сроки).

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