It is never just a button. How to balance business, development and architecture needs

1. It is never just a button
How to balance business, development and
architecture needs

2. About
https://www.drupal.org/user/773216
https://www.linkedin.com/in/pavel-makhrinsky

3. Ultimate Question of Life, the Universe,
and Everything
The Hitchhiker's Guide to the Galaxy

4. Real projects

5. Expectations
Customers
Cost efficiency
Maintenance cost
Predictable result
ROI
Interesting tasks
- new technologies
- trends
- new knowledge
Market value
Recognition
You are the developer, just make
me happy
I don’t want to think, I want a task

6. Processes
Code reviews
Design sprints
Meetings
Task flow
GIT flow
TDD
DevOps
Agile
Lean
Kanban
Design thinking
Waterfall
OKR
KPI
Methodologies

7. Tools
Task trackers
Metrics
- code quality
- development speed
- velocity
- ...
CI/CD
Autotests
Drush
Docker/Kubernetes
Scaffolders
Libraries (npm, composer...)

8. Is it working now?
Not really

9. Unicorns world’s life
Tester making system better
Developer looks for most suitable solution
PM helps team collaboration and removes obstacles
Customer defines business goals
Everything is overprocessed, hierarchy, and nothing
still works

10. Real life
Tester goal is to crash the system
Developer implement in time
PM focused on process
Customer gets average solution
Everything is overprocessed, overruled by hierarchy,
and nothing still works as expected

11. Caching story
- big system
- millions of records
- 100 web servers
- lots of backend servers
- great processes
- qualified team
- processes are not time wasting
- everybody fails
- trust

12. Communication
Mature team is not about seniority only
- trust
- no blaming
- weak and strength sides
- knowledge sharing
- common values
- understanding product
- Commuoneed sense: things have meaning

13. Product: what does it mean?
- understanding nature of the things
- why is it needed
- architecture
- domain area

14. Everything is a product
- communications
- processes
- customer needs
- tasks

15. Product thinking leads to architecture
not view, but news list
not block, but part of the bigger solution
not just docker, but predictable environment
...

16. What was it about?
Product thinking
Communication
Processes
Additional value

17. Questions?