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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

Обо всем по порядку.

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

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

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

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

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

Почти художественная заметка по мотивам документальных наблюдений :)

Множество интересных вещей можно заметить, если присмотреться к тематическим постам и вакансиям в области интерфейсов цифровых продуктов (UI, UX, etc.). Жизнь кипит, множество конференций, новые технологии и инструменты, выступления, тренды на следующий год… но что-то не стыкуется…

Дорогие друзья,
Мы работали днем и ночью, находили вдохновение в каждом моменте времени, писали код со скоростью Шумахера на трассе Формулы-1, проделали мощнейшую работу и достигли огромных результатов. Год выдался насыщенным и пролетел стремительно. Настало время подвести его итоги.

Начало
После периода безудержного кодинга, длившегося почти год, финальным шагом на пути к запуску Payler стало прохождение аудита PCI DSS. Мы официально запустились 1 мая – в праздник весны и труда – и начинали как платежный шлюз, предоставляющий только услуги интернет-эквайринга. Однако мы быстро поняли, что рынок требует свежих идей и новых инструментов.

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

Дорогие друзья!

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

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

Преамбула: «Что такое Payler сегодня?»
● Основные компоненты продукта: антифрод, ядро шлюза, публичные и внутренние API, модули процессинга, административные интерфейсы мерчанта, мобильные клиенты, внутренние утилиты;
● Продукту несколько месяцев, получен сертификат на соответствие PCI DSS, появились первые клиенты;
● Используемые технологии: C#, Python, Ruby, MySQL, Redis, Angular.js etc.;
● Команда:
○ Backend: 3 разработчика, которые периодически переключаются между компонентами;
○ Frontend: 1 разработчик;
○ Mobile: 2 разработчика — 1 iOS, 1 Android;
○ Системный администратор.