Розуміння в цілому

Проєкт потрібно починати з розуміння в цілому – що ми робимо, нащо ми це робимо, де та як воно буде використовуватись.

” – А! Це ж питання до бізнес-аналітиків – нащо інженерам знати це? Нехай BA ібуцця з бізнесом, не заважайте інженерам! ” – отаке можна почути від пересічного софтбудівника.

Отаке … але ніт.

Відокремлена вимога, відокремлена user story – це ґудзик від костюма у вакуумі. Без розуміння картини в цілому важко зробити, щоб “костюмчик гарно сидів”. Відчуття повного “костюму” на конкретного замовника важливо не тільки технічно, але й емоційно – бо інакше буде гидко, нудно, мутно та прикро.

Навіть ті хто з розробників каже що йому не цікавий бізнес дуже швидко перестає розуміти що ми кодимо та чому – бо навіть код вимагає життя. QA при плануванні тестів втрачає загальну картину операцій користувача, важко зрозуміти сценарії застосування. Архітектор не бачить всіх можливих нефункціональних вимог. UX не може знайти відповідного інтерфейсу. Менеджер втрачає культурний звязок у комунікаціях та аргументи щодо вимог.

Повне розуміння проєкту – це дуже важливий компонент для старту команди. Його також потрібно повторювати (у записі та додатковий mini-introduction) для нових членів команди. Загальне розуміння проекту є точкою інтеграції всіх функціональних напрямків, здобуття цінності завдяки використанню рішення є основою мотивації команди. Бо це дуже важливо – розуміти що ми робимо цілу магічну штуку яка принесе людям добро 🙂

Залишити відповідь