Документируйте то, что вы делаете или планируете делать

Трудным заданием для тех, кто любит программировать или управлять по наитию, является документирование. При необходимости можно «опередить события» и сделать экранный прототип, но экранные снимки делаются только ради конкретизации проектной документации. Не отдавайте прототип напрямую программисту, который должен завершать проект. Может показаться, что такой прототип сэкономит время, но он может просто повести программиста неверным путем и спровоцировать фальстарт. Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования – только начальный этап разработки документа, позволяющий обрисовать архитектуру, а дальше вы можете говорить о реализации решения в объектах кода. У вас всегда будет искушение, когда поджимает время (а разве бывает иначе?), слепить все «по-быстрому», однако надо быть настоящим счастливчиком, чтобы, не имея четкого плана, создать программный продукт, который можно будет в дальнейшем дополнять и обновлять.

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

Прототипы служат для обоснования готовой концепции, в то время как программные продукты представляют собой реализацию готового проекта.

Оценка вашей производительности

Как я упомянул в этой главе ранее, в момент, когда вы впервые превращаетесь из программиста с полной занятостью в начальника с полной занятостью и одновременно программиста с частичной занятостью, административная деятельность кажется не столь продуктивной, как кодирование. Учитесь различать просто трату нервной энергии и настоящее творчество. Что я имею в виду? Если вы привыкли кодировать часами, то вы поймете, что такое нервная энергия. Это то состояние вашего ума, когда вы прикончили уже три чашки кофе[27], вам еще писать и писать, но вы уже чувствуете приближение результата. Настоящее творчество – это ощущение, когда вы видите и конечный результат, и все ступени его достижения, но при этом знаете, что должное качество будет достигнуто далеко не так быстро. Я знаю, что все сказанное трудно переварить, но вам действительно нужно как следует обдумать эту концепцию.

Как программист вы привыкли измерять свою производительность числом работоспособных объектов, созданных вами в течение дня. Подобный метод оценки может стать причиной вашего провала как руководителя. Вы будете разочарованы и не удовлетворены тем, как вам приходится проводить время, пока не примете новый образ мышления. Как начальнику вам следует оценивать свою производительность объемом работы, которую выполняет ваш коллектив. Вы не можете оценивать этот объем каждый день, и это может стать серьезной проблемой, если вам требуются постоянные подтверждения того, что вы работаете хорошо. Как ежедневно решать эту проблему? Заходите к своим программистам каждый день или звоните им и проверяйте, как идут дела. Когда они привыкнут ждать этих ежедневных встреч, произойдут две вещи: они никогда не будут знать, когда вы появитесь, и, таким образом, постараются быть в «постоянной готовности», а вы сможете оценить их ежедневный прогресс и соответствующим образом подстроить под него свой график работы. При этом обе стороны прекрасно понимают, что происходит, однако приятно притворяться, что никто ничего не замечает.

Как начальнику вам следует оценивать свою производительность объемом работы, которую выполняет ваш коллектив.

В своей крайне проницательной книге «The End of Patience» Дэвид Шенк (David Shenk) пишет:

По аналогии с приведенной цитатой, не оценивайте вашу производительность тем, насколько быстро вы можете перепрыгнуть от одного проекта (или сотрудника) к другому. Не теряйте из виду масштабные цели и оценивайте небольшие шаги, необходимые для успешного достижения цели. Не занимайтесь самообманом – пусть реальное положение дел диктуется фактами, а не вашим оптимистичным воображением. Ключевые слова из предшествующей цитаты – «привлекательный» и «мышление». Не соблазняйтесь непосредственным удовольствием от кодирования; лучше поразмыслите, как помочь остальным получать это удовольствие под вашим руководством.

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

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

Контролируйте свои слабости

Вы великий программист, правда? Я уверен в том, что так оно и есть, а также в том, что вы все же еще не совершенны. Остерегайтесь, что ваши слабости как программиста заставят вас смотреть сквозь пальцы на тех в вашем коллективе, кто похож на вас. Если вы сами не любили документировать и проектировать, прежде чем начать кодировать, тогда вы, вероятно, можете позволить другим этого не делать.

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

Такие вещи вряд ли могут быть полезными. Если вы минималист, то в случае когда дело доходит до обработки ошибок (которых в идеале не бывает), вы можете не заметить отсутствия процедур обработки ошибок в коде Салли, считающей все настолько очевидным, что обработка ошибок – это просто трата места. Я могу продолжить перечень слабостей программистов, но оставлю это вам. Тем не менее вам требуется осознать необходимость постоянно быть внимательным к своим недостаткам как программиста, поскольку нельзя прощать другим то, что вы могли бы простить себе. Это может выглядеть противоречиво, и так оно на самом деле и есть, так что продолжайте работу над исправлением своих недостатков как программиста, чтобы не заразить ваших подчиненных теми же слабостями.

Чтобы вам было легче преодолевать свои слабости, представьте себе, что многие люди прошли тот же путь, что и вы. Некоторые из них проложили на этом пути вехи для вас – это книги и иногда URL-адреса. Другими словами, для того чтобы заполнить пробелы в знаниях и/или опыте, рекомендую побольше читать. Вам нужно читать по многим причинам. Вот некоторые из них: