Сейчас конец 2012-го года. Всё просвещённое человечество ожидает конца
света, предсказанного календарём майя, а мы вместо этого пишем годовой
отчёт. За 2011-й год. По идее, сдать его нужно было ещё летом. Но, как
всегда, находились более важные дела.
И вот время настало. Откладывать дальше нет никакой возможности: жребий брошен, Рубикон остался позади, все бросили работу над текущими проектами и занесли пальцы над клавишами. Ведь если отчёт так и не будет написан, то...
А действительно: что случится, если отчёт так и не будет написан? Зачем его пишут, кому он нужен и на что влияет?
Задумавшись над этими вопросами, я пришёл к некоторым выводам, о которых сейчас и пишу. Правда, есть одно уточнение: всё, изложенное далее, касается только разработки программного обеспечения, в чём я немного разбираюсь. В других областях дело может обстоять иначе.
Итак, кому нужен отчёт? Давая нам задание на написание годового отчёта, начальник подразделения сказал, что «это нужно в первую очередь вам». То есть, если вдруг нам понадобится узнать что-то из случившегося в 2011-м году, мы посмотрим в отчёт и всё там увидим.
Проблема в том, что я, например, занимаюсь программированием с двухтысячного года и, разумеется, писал много отчётов. И как-то так получилось, что за эти двенадцать лет мне ни разу не понадобилось перечитывать свои отчёты. Более того, читать чужие отчёты тоже необходимости не возникало. Не скажу «за всю Одессу», но полагаю, что у других разработчиков дела обстоят примерно так же. Если нам нужно узнать что-то, касаемо программного проекта, мы будем это искать в документации, а не в отчётах. Учитывая, что документации в подавляющем большинстве случаев не существует, мы либо обратимся с вопросом к тому, кто писал код, либо будем читать код непосредственно. Но в отчёт не полезем.
Для разработчика отчёт бесполезен, ибо никогда не читается. Даже вреден, потому как на его написание уходит драгоценное время, да и процедура сия выбивает из колеи надолго. Но зачем-то же эти отчёты придумали, правда? Значит, нужны они кому-то другому.
А именно — руководителю проекта. У него в подчинении толпа простых программеров и стоять у каждого за плечами, посматривая в код, он не сможет физически. А знать, в каком состоянии находится проект, надо.
Поэтому и должны писаться отчёты, из которых руководитель может получить представление о том, куда и как движется проект. И, если он движется не так и не туда, то внести коррективы.
Из этого следует несколько логичных выводов. Правильный отчёт должен:
Но тогда зачем писать годовой отчёт?
А писать его нужно затем, что всё, ранее написанное о правильном отчёте, к нему не относится. Потому что на самом деле отчёт адресован не руководителю проекта, а высшему руководству. И влияет не на то, куда движется проект, а дадут ли на этот проект ещё денег. Следовательно, такой отчёт должен:
Ну и, разумеется, время написания отчёта ни на что не влияет. Хоть через год его пиши — никаких значимых мер всё равно приниматься не будет.
Таким образом, написание правильных отчётов, честно отражающих положение дел, становится невыгодным. Выгодно гнать туфту и втирать очки. Это нужно понять и смириться.
Ещё в детстве я где-то (по-моему, в журнале «Вокруг света») читал занимательную историю про архитектора, строившего в далёком зарубежье некое внушительное здание (как бы не адмиралтейство британское). И когда проект был посчитан и представлен заказчикам, те возмутились. Как это так, строить такое сооружение — и без колонн! Оно же обрушится нафиг! Срочно изменить проект и добавить колонны!
Архитектор себе язык стёр, доказывая, что есть такая штука — сопромат, которая гарантирует, что ничего не обрушится. Но заказчики были непреклонны: нужны колонны, и никаких гвоздей! Точка.
В результате проект был изменён. В смету вписали стоимость дополнительных колонн, заказчики для порядка поохали («опять расходы непредвиденные!»), но подписали.
А когда всё было построено, выяснилась интересная штука. Колонны-то архитектор воздвиг, но... на полметра ниже, чем надо. Так что между верхушками колонн и перекрытиями, которые они, по идее, должны подпирать, осталось много пустого места. Скандал, конечно, был знатный, но не перестраивать же?
Так оно, здание это, и стоит до сих пор. С бесполезными колоннами, демонстрирующими правоту архитектора с его сопроматом и непроходимую тупость лордов-заказчиков с их «интуицией» и «нам лучше знать!».
Вот и ситуация с нашими годовыми отчётами чем-то похожа. Такая же бесполезная штука, на которую тратится время и деньги, и которую проще сделать, чем объяснить её бесполезность.
И вот время настало. Откладывать дальше нет никакой возможности: жребий брошен, Рубикон остался позади, все бросили работу над текущими проектами и занесли пальцы над клавишами. Ведь если отчёт так и не будет написан, то...
А действительно: что случится, если отчёт так и не будет написан? Зачем его пишут, кому он нужен и на что влияет?
Задумавшись над этими вопросами, я пришёл к некоторым выводам, о которых сейчас и пишу. Правда, есть одно уточнение: всё, изложенное далее, касается только разработки программного обеспечения, в чём я немного разбираюсь. В других областях дело может обстоять иначе.
Итак, кому нужен отчёт? Давая нам задание на написание годового отчёта, начальник подразделения сказал, что «это нужно в первую очередь вам». То есть, если вдруг нам понадобится узнать что-то из случившегося в 2011-м году, мы посмотрим в отчёт и всё там увидим.
Проблема в том, что я, например, занимаюсь программированием с двухтысячного года и, разумеется, писал много отчётов. И как-то так получилось, что за эти двенадцать лет мне ни разу не понадобилось перечитывать свои отчёты. Более того, читать чужие отчёты тоже необходимости не возникало. Не скажу «за всю Одессу», но полагаю, что у других разработчиков дела обстоят примерно так же. Если нам нужно узнать что-то, касаемо программного проекта, мы будем это искать в документации, а не в отчётах. Учитывая, что документации в подавляющем большинстве случаев не существует, мы либо обратимся с вопросом к тому, кто писал код, либо будем читать код непосредственно. Но в отчёт не полезем.
Для разработчика отчёт бесполезен, ибо никогда не читается. Даже вреден, потому как на его написание уходит драгоценное время, да и процедура сия выбивает из колеи надолго. Но зачем-то же эти отчёты придумали, правда? Значит, нужны они кому-то другому.
А именно — руководителю проекта. У него в подчинении толпа простых программеров и стоять у каждого за плечами, посматривая в код, он не сможет физически. А знать, в каком состоянии находится проект, надо.
Поэтому и должны писаться отчёты, из которых руководитель может получить представление о том, куда и как движется проект. И, если он движется не так и не туда, то внести коррективы.
Из этого следует несколько логичных выводов. Правильный отчёт должен:
- быть адресован руководителю проекта;
- писаться кратко и доходчиво, чтобы экономить время руководителя, который должен принимать решения быстро;
- честно отражать состояние проекта — если исходные данные неправильны, то и результаты правильными не будут;
- быть актуальным — если что-то надо корректировать, это надо делать сейчас, пока ещё можно.
Но тогда зачем писать годовой отчёт?
А писать его нужно затем, что всё, ранее написанное о правильном отчёте, к нему не относится. Потому что на самом деле отчёт адресован не руководителю проекта, а высшему руководству. И влияет не на то, куда движется проект, а дадут ли на этот проект ещё денег. Следовательно, такой отчёт должен:
- писаться не кратко и доходчиво, а длинно и запутано — чем меньше из него поймут, тем лучше;
- выглядеть внушительно — чем круче работа выглядит, тем больше вероятность, что её профинансируют;
- создавать впечатление, что «всё хорошо, прекрасная маркиза!», даже если любой разработчик понимает, что проект на грани краха.
Ну и, разумеется, время написания отчёта ни на что не влияет. Хоть через год его пиши — никаких значимых мер всё равно приниматься не будет.
Таким образом, написание правильных отчётов, честно отражающих положение дел, становится невыгодным. Выгодно гнать туфту и втирать очки. Это нужно понять и смириться.
Ещё в детстве я где-то (по-моему, в журнале «Вокруг света») читал занимательную историю про архитектора, строившего в далёком зарубежье некое внушительное здание (как бы не адмиралтейство британское). И когда проект был посчитан и представлен заказчикам, те возмутились. Как это так, строить такое сооружение — и без колонн! Оно же обрушится нафиг! Срочно изменить проект и добавить колонны!
Архитектор себе язык стёр, доказывая, что есть такая штука — сопромат, которая гарантирует, что ничего не обрушится. Но заказчики были непреклонны: нужны колонны, и никаких гвоздей! Точка.
В результате проект был изменён. В смету вписали стоимость дополнительных колонн, заказчики для порядка поохали («опять расходы непредвиденные!»), но подписали.
А когда всё было построено, выяснилась интересная штука. Колонны-то архитектор воздвиг, но... на полметра ниже, чем надо. Так что между верхушками колонн и перекрытиями, которые они, по идее, должны подпирать, осталось много пустого места. Скандал, конечно, был знатный, но не перестраивать же?
Так оно, здание это, и стоит до сих пор. С бесполезными колоннами, демонстрирующими правоту архитектора с его сопроматом и непроходимую тупость лордов-заказчиков с их «интуицией» и «нам лучше знать!».
Вот и ситуация с нашими годовыми отчётами чем-то похожа. Такая же бесполезная штука, на которую тратится время и деньги, и которую проще сделать, чем объяснить её бесполезность.
Комментариев нет:
Отправить комментарий