Roky sa točím okolo vývoja SW. Môj sen je, aby sa všetci cítili štastní, naplnení a plní nadšenia, na čom budú makať zajtra. Aby sme robili na veciach, ktoré majú zmysel. Som svedkom, že stále máme rezervy. Na projektoch, ktorých sa ja zúčastňujem vždy spolupracujem s inteligetnými ľudmi, ktorí su expertami v tom, čo robia (vo svojej doméne). Klúčove oblasti, ktoré našu vzájomnú spoluprácu ovplyvňujú sú:
- vzájomné porozumenie
- vzájomná dôvera
V týchto oblastiach sú by default trhliny. Takže spôsoby, akým projekty, a tým pádom ľudí riadime (motivujeme, manažujeme, vedieme), následne majú vplyv na to, či trhliny scelujeme, alebo ešte viacej rozdrapíme.
Kedže sa posledné roky intenzívne kope do vodopádu (sám som vinný) a zároveň som svedkom, že dogmatické followovanie agilných metodík, povedzme SCRUM-u tiež neprínáša želané alebo očakávané výsledky, som na ceste hľadania. Už nejaký čas analyzujem práve trhliny v komunikačnej časti, a teraz som
a) narazil na túto hypotézu:
I wonder if a regression towards waterfall is intrinsic to any process where developers aren’t trusted.
Zdroj: https://daedtech.com/in-devs-we-trust/#comment-3989
Bolo to na blogu chlapíka Erika Dietricha, ktorý mimochodom píše zaujímavé reflexie (ranty :-)) pre bublinu softvérových vývojarov (a vlastne všetkých okolo tejto bubliny). Jeho knihu Developer hegemony som síce zatiaľ nečítal, ale jej vystihújuce zhrnutie je istým zrkadlom aj pre mňa samotného:
it's the crazy idea that software developers should be in charge of software development
b) zároveň v tom čase spoločnosť Basecamp vydala (zadarmo) knihu, lepšie povedané príručku, Shape up, pre mladého padawana i starého jediho, či je to developer, projektový manažér, alebo analytik, dizajnér, ktorú práve lúskam. Pár dní späť som počúval podcast s Ryanom Singerom, ktorý je autorom tejto príručky. A tam ma to udrelo druhý krát, že práve práca v dvoch vláknach (viac nižšie) pomáha veľmi tomu, aby všetci participanti cítili dostatočný komfort (viem, čo mám robiť, netopím sa, a mám hranice) a zároveň dostatok priestoru pre svoju sebarealizáciu (neni som len výrobná linka). Inak povedané, nestrácali vnútornu (intristic) motiváciu.
Shape up
Za podtitulom príručky Shape Up Stop Running in Circles and Ship Work that Matters stoji primárne rozdelenie práce na 2 procesy/vlákna:
- (hrubé) tvarovanie - odtiaľ meno knihy - strategická práca na priprave projektu, aby ho bolo možné doručiť v definovaných (a zároveň želaných limitoch)
- design a výroba - zodpovednosť za dodanie fungujúcej veci v definovanom časovom rámci (6 týždnov)
Kým sa urobí stávka (použitie tohto termínu je zámerné) na projekt, projekt najprv prechádza fázou tvarovania. Z tejto fázy (keď pominiem fázu schválenia stakeholdermi) je odovzdaný na dizajn/výrobu, avšak v stále vo forme, ktorá umožnuje exekúcii (designer, developer) aplikovať svoju expertízu. Tieto dve fázy sa nikdy nepretínajú. Pointa tvarovania je dosiahnuť good enough detail toho, čo má byť vyrobené.
Toto je premňa zrkadlom a benchmarkom pre moje vlastné postupy a nápady, ako byť súčasťou efektívneho, motivovaného a stále štastného tímu, ktorý je zložený z rôznych expertov, ktorí nadôvažok nemusia byť výhradne pod dáždnikom jednej organizácie (v prípade Basecampu sú všetci pod jednou strechou).
Budem to teda ďalej skúmať a informovať. Ty si odnes túto info:
- najdi si developera, ktorému veríš
- daj mu dostatok priestoru, aby sa mohol realizovať
Toto všetko má pozitívne dopady na dostatok času pre obe strany (eliminácia mikromanažmentu, ochrana developera pred stakeholderom).
Teraz choď, a začni čítať Shape up. Asi to nie je posledný krát, čo tu o ňom počuješ.