Customer satisfaction для программистов

Часто разработчики говорят мне, что soft skills им не нужны. Разработчик — не менеджер и управленческие навыки может не развивать. С одной стороны так и есть — разработчику очень важно углублять свои знания в технологиях и методологиях проектирования ПО. С другой стоны, я уверен, каждому хочется уметь отстаивать свою позицию и получать заслуженную похвалу за хорошую работу. А если так, то почему бы не продвинуться в этом направлении?

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

Серия статей «Customer satisfaction для программистов»

Материала получилось довольно много, поэтому каждый раздел выйдет отдельной статьей:

• Визуализация
• Доверие и прозрачность
• Все программисты — оптимисты
• Проблем быть не должно
• Используем Domain Driven Design

Под «заказчиком» я имею ввиду любые отношения заказчик-исполнитель, где вы являетесь исполнителем. Заказчиками могут быть пользователи вашего продукта, может быть Project Manager, может быть совет директоров, может быть бухгалтер из соседнего отдела и т.д.

Всё, о чём будет идти речь, точно сработает, если вы действительно хорошо сделали свою работу. Мы не будем рассматривать случаи, когда качество работы низкое и стоит задача убедить заказчика в обратном.

Модель принятия решений

Когда-то меня вдохновило выступление Евгения Кривошеева Design & Process Models. В нём рассматривается много аспектов разработки ПО, рекомендую выделить 2 часа и посмотреть видео целиком. Сейчас я хочу остановится на взаимодействии связанных между собой моделей и том, как это можно использовать в повседневной работе:

• Business Model — бизнес заказчика, на чём он зарабатывает деньги.
• Process model — как должен быть устроен процесс формирования ценности: этапы, фазы, роли, артефактры для получения ценности. Описывает также порядок появление нижележащих моделей и их взаимодействие. Например, пишем код и рефакторим до хорошего дизайна или сначала делаем дизайн (upfront) и потом пишем код.
• Requirements Model + Domain Model — какие требования есть к продукту/проекту, тексты, UML-диаграммы и т.д.
• Design Model — архитектура, шаблоны проектирования и т.п.
• Implementation Model — исходный код

Impact Mapping на практике

Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

Смотрите видео с мастер-класса по Impact Mapping

Command and Query Responsibility Segregation (CQRS) на практике

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

Возможно, вы уже используете CQRS, сами того не зная. Изучение данной темы поможет структурировать приемы, характерные для CQRS, использовать общепринятые названия в коде и разговаривать с коллегами на одном языке, оперируя понятиями команд и запросов.

IT-образование в ВУЗах

Окончился очередной учебный год в университете. Ниже будет мой отчет по работе на IT-специальности. Возможно кому-то тема обучения в ВУЗе близка, буду рад вашим комментариям и замечаниям, идеям как можно сделать лучше.

На данный момент у меня 4 года опыта преподавания в ВУЗах. Первые 3 года вел ООП и Технологии программирования у 4-го курса на кафедре Информатики в ЮУрГУ. Этот опыт я уже описывал в статье Обучение IT-специалистов в университете. Текущий год я провел на ВМИ в ЮУрГУ и эпизодически в ЧелГУ на нескольких лекциях.