Мотивация и системы мотивирования

• Обладать юзабилити, то есть быть удобным в применении: пользователя можно обучить работе с продуктом, не прилагая сверхусилий; постоянная обратная связь от пользователей учитывается при улучшении версий и приводит к повышению удобства использования; пользователям нравится продукт, они выбирают именно его среди аналогичных.

• Повышать операционную эффективность: оптимизировать ресурсы, требуемые для функционирования системы; работать при возрастающих нагрузках и неблагоприятных условиях.

• Быть способным к улучшению: обеспечивать возможность быстрого обнаружения и исправления ошибок (багов), упрощать тестирование при сохранении качества, повышать скорость адаптации к изменениям.

• Иметь высокую применимость: быстро адаптироваться к разным условиям использования и различным платформам; просто и надежно осуществлять процесс инсталляции и конфигурирования продукта; эффективно заменять все аналоги в этой нише.

В современных ИТ-продуктах и их рыночной представленности возник и расширяется явный разрыв между тем, что нужно потребителю, и самовыражением разработчиков. При этом многие устройства требуют обновления хорошо работающих программ на постоянной основе – иначе исчезают прежде существовавшие сервисы, объем функций ограничивается, обмен данными между разными версиями программ становится сложным или невозможным, и тот же персональный компьютер превращается в «пишущую машинку» с ограниченной функциональностью. Есть ощущение, что каждое новое обновление запускается ради самого факта изменения, а не в связи с объективной потребностью пользователей. Потребитель вынужден использовать сырые обновленные программы, чтобы сохранить возможность работы со своими устройствами. Это очень похоже на рэкет со стороны компаний-производителей. Например, Apple предупредила, что многие новые программы не будут тестироваться, а то и создаваться для устройств, которым более пяти лет с момента выпуска. Это означает, что потребители либо должны приобрести новое устройство (обрадовав трудолюбивый Китай, но пополнив планету новым шквалом отходов пластика), либо отказаться от использования привычного устройства. Ну, либо смириться с тем, что впредь программы на их (старом, но вполне рабочем) устройстве будут работать еще хуже, чем сейчас, и неизбежно перестанут поддерживать нужную функциональность. Раньше срок гарантии на продукты был до семи[67]

, а то и до десяти лет. Этика темы зависимости людей от гаджетов пугающе выползает из тени.

Однако не все могут позволить себе такие вольности с потребителем.

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

Между требованиями к разработчикам ИТ-продукта, «внедренцам» и руководителю ИТ-проекта существует разница. Основное обобщенное различие состоит в балансе технических знаний и умений и менеджерских навыков. Разработчик может себе позволить быть угрюмым букой, если в проекте есть кто-то – тот же тимлид фронтенд-разработки, – который обеспечивает всю коммуникацию между финальным заказчиком и командой, создающей продукт. У тимлида есть задачи, связанные с текущим проектом, но существенным требованием к его компетенциям является необходимость рыночного чутья и отслеживания продуктовых и технологических трендов, чтобы вовремя привносить в проект новинки, усиливающие отрыв от конкурентов.

Тимлид, таким образом, обязан обладать компетенциями в коммуникациях, менеджменте, маркетинге и технологиях.

Разработчик

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

Как образно сформулировала Юлия Нестерова, разработчики любят тепличные условия, поэтому тимлид должен быть щитом, защищающим их от внешнего мира.

Кадровый голод на ИТ-специалистов побуждает работодателей пытаться совмещать разработчика и тимлида в одном лице, но из сказанного выше очевидно, что это неоптимальное решение: пострадает либо функция разработки, либо функция маркетингового прогноза и коммуникации с заказчиком.

Различаются и мотивационные подходы.