«Нажали одну кнопку, и всё появилось». Рабочий процесс разработки в моей ИТ-компании
У каждой профессии есть свой способ бесить людей не принадлежащих к этой профессии. Врачи для этой цели используют почерк, военные разговаривают матом, а разработчики, когда просишь их прислать список того, что они умеют, делают так:
TypeScript/JavaScript/Golang, React/Angular, NestJS, Express, PostgreSQL, MySQL, MongoDB/Mongoose, Redis, RabbitMQ, NATS,REST, GraphQL, JSON-RPC, gRPC, Websockets, TypeORM, Sequilize ORM, Telegraf, Web3, Swagger, Jest, Mocha/Chai, Webpack, Docker, Docker Compose, Nginx, AWS, Prometheus, Grafana, GitLab
И тут мозг потенциального Заказчика плавится🫠 , ведь у него просто есть запрос, например, на создание корпоративного портала, и бюджет на его реализацию. А как этот запрос будет реализовываться ему, чаще всего, до лампочки, потому что ничего не понятно 🧐 .
В декабре я поменял направление своей компании с классической системной интеграции на разработку, так как с железками стало всё сложно (но их не бросаем), и передо мной встал вопрос, а как сделать процесс разработки максимально открытым и понятным для Заказчика?
⚠️ Отталкиваться стал от мысли, что каждый процесс должен приносить результат, ведь продукт должен заработать, как можно скорее. Быстрое внедрение проекта в работу выгодно обеим сторонам: Заказчик раньше начнет привыкать к продукту и в большинстве случаев сэкономит бюджет, а Исполнитель поймёт, в каких местах есть ошибки и сможет их оперативно исправить.
Во время создания ТЗ и описания процессов весь проект разработки делится на этапы. Их количество зависит от продукта, который мы собираемся разрабатывать. После завершения этапа мы сдаём его в эксплуатацию для сбора обратной связи. Если мы понимаем, что нужно вносить правки, мы возвращаемся к процессам и улучшаем результат.
✅ При таком подходе процесс работы становится максимально прозрачным и напоминает понятный цикл с условиями (см. картинку к посту).
#самореклама
У каждой профессии есть свой способ бесить людей не принадлежащих к этой профессии. Врачи для этой цели используют почерк, военные разговаривают матом, а разработчики, когда просишь их прислать список того, что они умеют, делают так:
TypeScript/JavaScript/Golang, React/Angular, NestJS, Express, PostgreSQL, MySQL, MongoDB/Mongoose, Redis, RabbitMQ, NATS,REST, GraphQL, JSON-RPC, gRPC, Websockets, TypeORM, Sequilize ORM, Telegraf, Web3, Swagger, Jest, Mocha/Chai, Webpack, Docker, Docker Compose, Nginx, AWS, Prometheus, Grafana, GitLab
И тут мозг потенциального Заказчика плавится
В декабре я поменял направление своей компании с классической системной интеграции на разработку, так как с железками стало всё сложно (но их не бросаем), и передо мной встал вопрос, а как сделать процесс разработки максимально открытым и понятным для Заказчика?
Во время создания ТЗ и описания процессов весь проект разработки делится на этапы. Их количество зависит от продукта, который мы собираемся разрабатывать. После завершения этапа мы сдаём его в эксплуатацию для сбора обратной связи. Если мы понимаем, что нужно вносить правки, мы возвращаемся к процессам и улучшаем результат.
#самореклама