Эффективность — один из главных показателей успешности работы. Применительно к отрасли программного обеспечения можно говорить как об эффективности процесса разработки ПО и отдельных его участников — программистов, инженеров контроля качества, аналитиков, так и об эффективности собственно программы. В первом случае речь идет об эффективном использовании времени инженеров, во втором — о вычислительных ресурсах (процессорное время, память, пропускная способность каналов связи). Кстати, эффективность программы — один из важных нефункциональных критериев качества в терминах методологии SQALE, упоминать которую я стараюсь почаще, чтобы привлечь к ней внимание разработчиков. Но это отдельная увлекательная тема.
В этой же статье я хотел бы отметить важность эффективности процесса разработки ПО и отдельных его участников. В том числе и потому, что с ростом производительности вычислительных систем важность эффективности программ снижается, а важность эффективности программистов и процесса разработки только растет.
Что же такое эта самая «эффективность»? Попробуем дать определение от противного, представим, что «эффективность — это отсутствие неэффективности». Практическое удобство такого определения в том, что неэффективность зачастую очевидна, ее результаты легко осознать и измерить. Следовательно, оценить эффективность, к примеру, процесса удобнее, демонстрируя его неэффективный вариант, которого удалось избежать.
Казалось бы, если важность эффективности растет, и все это понимают, то к чему вынесенный в заголовок призыв к её защите? Ведь каждый стремится к тому, чтобы быть по возможности более эффективным?
Не тут то было! При продаже сервиса по разработке, а не конечного результата (как в случае с продуктовыми компаниями), мы сталкиваемся с очень коварной проблемой: неэффективность продаваема.
Будем откровенны, зачастую, до определенного предела, конечно, затратить на решение одной и той же задачи больше часов означает пропорционально больше заработать. Более того, решив задачу быстрее с тем же качеством, мы зарабатываем меньше.
Возможность работы по схеме T&M (Time & Material) для нашего бизнеса — это как «голландская болезнь» для сырьевых экономик. Серьёзная и непосредственная опасность здесь состоит в том, что в долгосрочной перспективе компании, имеющие пагубную привычку продавать неэффективность, подрывают свою конкурентоспособность. Причем речь идет как о конкурентоспособности компании в целом на рынке заказов (особенно ярко это проявляется в способности конкурировать за заказы «по фиксированной цене»), так и в конкурентоспособности отдельных инженеров как внутри компании, так и на рынке труда.
Эффективность процессов в большей степени важна для проектов крупных и долгосрочных. Начиная с определенного порога
На проектах небольших на первый план выходит эффективность отдельных участников разработки. С точки зрения бизнеса последствия неэффективности на небольших проектах редко бывают катастрофичными, так как неэффективного разработчика вовремя замечают и принимают меры по «усилению» команды. Но для карьеры (и самолюбия) самого такого неэффективного инженера последствия могут быть серьёзными.
Формат статьи не позволяет детально рассмотреть практические примеры неэффективности, причины, способствующие возникновению неэффективности, и способы борьбы с ней. Но в целом можно отметить, что эффективность чаще всего достигается на проектах, участники которых отличаются дисциплинированностью, кропотливостью, ответственностью, вниманием к деталям и систематическим подходом к обучению (причем речь идет как о получении академических знаний, так и об изучении своего собственного проекта). С другой стороны, неэффективность — это практически всегда следствие лени, невежества и безразличия. Я знаю, что подобные утверждения зачастую воспринимаются настороженно, особенно серьёзные опасения вызывает слово «дисциплинированность». Призываю всех скептиков к открытому обсуждению подобных опасений. В свою очередь с удовольствием поддержу подобные дискуссии.
Нельзя не отметить, что одним из важнейших факторов достижения эффективности является способность распознать неэффективность, пусть даже постфактум, даже когда что-либо исправлять уже поздно. Распознать и поделиться информацией. Поделиться — значит понять, научится. Причем учится и понимает не столько тот, с кем поделились, сколько тот, кто делится.
Поэтому в качестве практического совета по самомотивации в борьбе за эффективность я призываю каждого делиться со своим руководителем примерами эффективных решений. Для этого нужно «предъявить» альтернативные сценарии: выработанный (эффективный) и тот (неэффективный), которого удалось избежать. Отмечу, что ряд подразделений уже официально добавили способность к выработке эффективных решений в список экспертных навыков, характеризующих квалификацию.
В заключение хочется сказать, что нам всем предстоит ещё многое сделать на пути увеличения эффективности. Увеличение эффективности процессов требует серьёзных слаженных усилий со стороны как инженеров, так и руководителей различных уровней, а зачастую это невозможно без привлечения заказчика. Но в основе всего лежит именно персональная эффективность каждого из нас: программиста, аналитика, контролера качества, руководителя.
И ещё одно: эффективность — это ключ к продуктивности. А быть продуктивным очень приятно. Надеюсь, те, кому довелось это испытать, меня поймут, а прочие захотят попробовать.
Автор статьи — технический директор компании Itransition.
