Материал входит в серию статей о build vs buy в HRTech.

Вынося роль Product Owner за скобки, попробую описать актуальную ролевую модель типовой команды.

В современных реалиях ядро команды разработки пользовательского приложения — а именно из таких решений в значительной степени и состоит HRTech — невозможно без трёх ролей: frontend-разработчика, backend-разработчика, UX/UI-дизайнера.

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

Если не рассматривать low-code-разработку, то необходимость frontend- и backend-разработчиков очевидна уже на этапе работы над MVP. С дизайном это не всегда кажется столь же очевидным — но, на мой взгляд, зря.

В современных HRTech-продуктах качество пользовательского опыта становится критически важным фактором принятия и использования. Речь не только о визуальной привлекательности интерфейса, а о том, насколько он понятен, последователен и помогает пользователю быстро выполнить нужное действие. Без этого даже сильная по функциональности система рискует остаться без финансирования. Именно поэтому я считаю роль дизайнера частью обязательного ядра команды. Причём не только на этапе начала разработки интерфейса, но и как можно раньше.

Лучше, чтобы реалистичные макеты появились уже в момент защиты бюджета. Не потому, что только ими всё ещё можно «продать» продукт, — эти времена, надеюсь, уже прошли, — а потому, что визуализация помогает людям гораздо быстрее понять, что именно они хотят делать в системе и как это должно работать. Это особенно важно в разговоре со стейкхолдерами, включая топ-менеджмент: интерфейс считывается быстрее, чем текстовое описание, и позволяет обсуждать не абстрактную идею, а конкретный пользовательский сценарий.

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

Читайте полную версию https://dzen.ru/a/ae-ooaiLEzJN5gYz