Оценка результатов разработки

У Элияху Голдратта есть замечательная книга, бизнес-роман «Цель». В нём подаётся много умных мыслей, которые я не однократно пытался натягивать на разработку ПО (ведь по сути, разработка ПО сравнима с изготовлением любой другой продукции, только вместо станков — программисты, а вместо сырья — программный код и среды разработки). Но лично для себя я вынес одну мысль, которая сильно упростила процесс передачи готового ПО заказчику и оценки результатов. У всего должна быть цель. И чем более чётко цель сформирована и чем лучше её понимают все участники процесса — тем быстрее и проще происходит внедрение новых разработок.

Как и у любого другого производства, у разработки ПО есть одна глобальная цель — удовлетворение спроса. В данном случае, спрос — это потребность Заказчика в разработке нового модуля или доработке существующего функционала. Исходя из этого, вся команда разработки должна работать на одну общую цель — удовлетворить потребность Заказчика. Руководитель отдела должен выстроить технологию разработки таким образом, чтобы требование Заказчика было правильно понято, аккуратно документировано, прилежно формализовано и красиво подано в виде готового продукта.

Вот мы и получили готовый продукт на выходе, заказчик радостно подписал акт приёма-передачи, и в большинстве случаев (ели речь идёт не про тиражный продукт) для команды разработки процесс формально заканчивается. По-умолчанию считается что требования Заказчика выполнены, спрос удовлетворён. Но так ли это? Тиражные продукты используют для этого методы отзывов и обратной связи. Собранные таким образом данные становятся основой для выпуска новых версий, патчей и апдейтов. Так почему бы не применить этот же метод в рамках IT отдела обычной компании? Опыт показывает, что сбор сведений о результатах разработки помогает оценить удовлетворённость клиента, причём во вполне измеряемых показателях, которые могут войти в структуру KPI программистов. Эти же параметры помогут руководству компании понять, насколько хорошо выстроена работа внутри отдела, при этом не вникая в суть современных методологий управления отделом. Эти же показатели помогут обосновать найм дополнительного специалиста и показать выгоду от каких-либо инноваций и затрат на отдел.

Сбор статистики и обратной связи вполне может быть как личным, так и автоматизированным. А лучше скомбинировать.

При личном сборе — тимлид или бизнес-аналитик с помощью телефонных звонков или личных встреч собирают ответы на вопросы стандартной анкеты и анализируют полученную статистику в конце отчётного периода.

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

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

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

Пример анкеты приводить не буду. т.к. каждая компания уникальна и может использовать диаметрально противоположные подходы к оценке работ.

Добавить комментарий

Ваш e-mail не будет опубликован.