True Engineering
Создаем цифровые продукты - trueengineering.ru Проектирование продуктов / Дизайн / Веб-сервисы / Мобильные приложения/ Разработка backend и API
в скором будущем переведём на английский, ссылкой поделимся
вся затея была как раз ради того, чтобы люди друг другу не писали ни в почту, ни в мессенджеры. подписантам и так валится куча писем, заявки на документы могут потеряться или сползти вниз в списке приоритетов
плюс, когда всё происходит по переписке, трудно работать с ожиданиями - непонятно, начали уже работать по запросу или пропустили письмо, сколько ждать результат и проч.
формализованный процесс работает в два-три клика: сотрудник нажимает кнопку "Мне нужна бумажка", подписант нажимает кнопку "Сделать бумажку". и всё - никто ничего не забывает, никто никуда не ходит, процесс идёт чётко и с предсказуемыми сроками.
эта история как раз про процессы - создать единую систему координат для всех продуктовых команд. чтобы у них не было желания и необходимости изобретать собственные велосипеды.
прежде чем переводить всех на единый шаблон, мы пообщались с разработчиками и составили общую картину, которую и воплотили в этом подходе. то есть этот шаблон родился из жизни и десятков, если не сотен проектов у нас за спиной. на данный момент мы исходим из того, что критической необходимости что-то менять ни у кого не возникнет
что касается метрик, то в данном случае мы ставили во главу угла Time-to-Market. единый шаблон - это единые процессы, а единые процессы - это предсказуемый результат. плюс, все разработчики мыслят в одном ключе, который в себе объединяет лучшие наши практики. опять-таки, всё родилось из опыта
цифрами пока поделиться не можем, возможно, вернёмся к этой теме, когда накопим данные
спасибо за уточнение) мы готовили инструкцию по информации с ПГУ - там в этом пункте УЦ не упоминаются
развитие не остановить - от наличных денег граждане уже почти отвыкли, электронные услуги наверняка тоже будут только развиваться
на каждом новом сайте нужно авторизоваться заново и получать новый токен, повторное использование угрожало бы безопасности пользователя
Пока не давали, но идея, в целом, интересная)))
спасибо, сейчас поправим
На собеседованиях спрашиваем кандидата в различных вариациях, как он принимал решения по тому или иному поводу. Главное, слушать ответы — будет это «я решил так или вот так» или «мы собрали совещание, подумали и приняли общее решение что…». И почему именно такое. А вообще, если тема интересна, могу написать статью.
В среднем срок работы в IT-компаниях 2-3 года, даже у мировых гигантов. У нас же получилось 5 лет, поэтому и решили поделиться опытом в статье.
Компания тоже выросла за этот срок: раньше эти 27 % составляли 2/3 всех сотрудников.
Александр, спасибо! Все верно!
Александр, демо-приложение сделано для внутренних нужд данного проекта и заказчика. Распространять не планируем.
Добрый день!
Рады, что статья была полезной.
Вся суть как раз в привязанности к заказчику. Без нее UI kit превращается в безликую библиотеку компонентов.
Разница между такими библиотеками и дизайн-системами в том, что библиотеки дают конструктор. Дизайн-система же подразумевает наличие индивидуальных в глобальном плане, но общих в рамках компании правил взаимодействия с пользователем.
Чтобы понять эту разницу можно посмотреть вот эти дизайн-системы: https://github.com/alexpate/awesome-design-systems. В них во всех есть описанная и довольно четкая «дизайн-философия».
В этом случае сотрудник должен отправить заявку повторно. Но есть 2 варианта:
1. Если это ежегодное планирование, то он видит свою исходную заявку и может просто нажать кнопочку отправить (менять или не менять даты – на его усмотрение)
2. Если это перенос существующего, то ему нужно делать новую заявку на перенос