Попробую поразмышлять: как должен выглядеть правильный процесс производства систем?
Сейчас больше пишут о жизненном цикле и создании продуктов, наверное, это правильно. Системы сами по себе не нужны, только если они наносят какую-то пользу каким-то людям.
В капиталистическом мироустройстве пользу нужно завернуть в продукт и продавать. ИТ система - это составная часть продукта.
Так как же правильно строить эти самые ИТ-системы?
Идея выстроить конвейер достаточно очевидна. Выделим основные этапы:
- Определение целей строительства системы
- Детализация процессов взаимодействия пользователей и системы
- Проектирование
- Разработка системы
- Тестирование
- Опытно-промышленная эксплуатация
- Промышленная эксплуатация
Далее разумеется сбор обратной связи от пользователей и заход на второй виток, но мы туда не пойдем.
Если все максимально упростить, то сначала нужно понять что хотим, потом придумать как, далее сделать и проверить что все работает.
Казалось бы, какие тут споры - поставьте на каждый этап ответственных и хорошо...
но давайте подробнее разберем производство (первые 5 этапов), на картинке ниже отражено распределение ответственности по ролям, а также конкретные результаты на каждом из этапов.
Все, вопросов нет? "Семья и школа" дали нам единственно правильный ответ?
Но внимание вопрос: почему же в реальной жизни все так сложно?
Не проще ли все свести к взаимодействию 2х человек Заказчика и Исполнителя. Бизнесмен скажет что нужно, а Программист сделает, если накосячит, то можно переделать. Так же быстрее!? А скорость вывода новых фич - это залог успеха бизнеса.
Главная проблема, которая получается от такой скоростной разработки - отсутствие понимания "Как работает система".
Но зачем я привел этот пример заведомо плохой работы?
Чтобы вывести простую мысль: если каждый исполняя свою роль будет просто делать свою часть работы как на конвейере, то такая самоизоляция приведет и приводит к тому что:
- аналитик выбирает сложное решение вместо простого, "а что мне сказали я сделал",
- код пишется долго и в результате получается не то, "ну как понял требования так и реализовал",
- тестировщик придумал кучу тестовых сценариев, ни один из которых не воспроизводится на практике, "я просто пытаюсь хорошо делать свою работу!"
Мораль сей басни такова: нужно обсуждать технические детали всей командой, когда передается эстафетная палочка.
Перед тем как бежать на следующий этап, нужно задать вопросы и понять почему выбрана именно такая реализация.
Очень хорошо, если квалификация каждого игрока в команде шире чем его роль, профессионализм идет "в нахлест" и частично покрывает смежные области.
