Баща, съпруг, маниак на технологиите, ветеран, блогър, пътешественик, кулинар, музикант – това е, общо взето, Джим Холмс – главен инструктор в Pillar Technology, където работи с организации, търсещи начин да подобрят своите процеси на разработване и внедряване на софтуер. Озовавал се в най-различни краища на ИТ света, откакто е станал част от ВВС на САЩ през 1982. Изпробвал е различни развойни среди, но предпочита тези, които прилагат практиките на Lean и Agile обществата.
„Защо” е въпросът, който той ще зададе многократно при откриване на конференцията ISTA 2015 (18 и 19 ноември, Sofia Event Center). Надява се с това да вдъхнови хората да си задават въпроса „Защо?” по-често в живота си. Това, в общи линии, ще съпътства тяхната работа по създаването на софтуер, но „Защо?” се отнася и за целия ни живот като човеци.
„Да си задаваме въпроса „Защо?” ни помага да разчупим усложнените си нагласи и превръща софтуерните екипи в истински служители на клиента. „Защо?” ни помага наистина да разберем от какво има нужда потребителят, за да реши своите проблеми, вместо да му даваме софтуер, който е – твърде често – безкрайно неподходящ за него и с ниска стойност.
Г-н Холмс, в резюмето на своята презентация казвате, че „съзнателното и уважително завръщане към приетите норми в осигуряване на софтуера може да ни помогне да предоставим много по-голяма добавена стойност за потребителите”. Означава ли това, че в днешно време софтуерните компании понякога забравят за „общоприетите норми в доставката на софтуер”?
Общоприетите норми твърде често биват сляпо и безмозъчно следвани! Вземете за пример „добрите практики” или „ISO стандарта”. Нито един от тези подходи не работи добре за цялата гама от софтуерни проекти. Доставката на софтуер далеч не е утвърдена наука или инженерна дисциплина. Ние трябва постоянно да надскачаме своите граници, да сме в процес на постоянно учене. Въпросът „Защо?” ни кара да видим как можем да използваме своите принципи и да адаптираме своите практики така, че най-добре да съответстват на всяка ситуация.
А възможно ли е да съчетаем най-новите развойни практики със старите, общоприети норми за софтуерно осигуряване?
В качеството ни на софтуерни специалисти, нашите принципи и ценности трябва да ни водят към това да правим абсолютно най-доброто за своите клиенти. Много пъти това може да означава избягване на „най-горещите” подходи или инструменти, защото средите на клиентите няма да го поддържат (тук следва да сме наясно, че „клиентите” могат да бъдат външни или вътрешни).
Ако ние подаваме дадено решение на клиента, то трябва и да гарантираме, че той ще е в състояние да го внедри успешно и да го поддържа, след като ние сме готови. Това не винаги може да се случи, ако натискаме „ножа до кокала” с нови развойни практики и инструментални средства. Инструментите много бързо изпадат в немилост – просто вижте колко бързо се променя пейзажът при JavaScript библиотеките!
Имайки предвид всички тези нови подходи, добри практики, стандарти и общоприети норми, регулации, правни рамки и изисквания, можем ли да избегнем попадането в „заплетени процеси”, за каквито ще говорите на ISTA 2015 в София?
Заплетените процеси често се основават на съчетание от политики, СНС (Страх, Несигурност и Съмнение), както и на човешката природа на съпротива към промените. В един момент, някъде в далечното минало, е възникнала вероятно основателна, солидна причина за започване на даден процес; тази причина обаче се е превърнала в нещо твърде тежко и обременяващо, движено от инерцията, което пречи на подобрението. Още по-лошото е, че задушава способността бързо да се доставя стойност своевременно!
Да си представим необходимостта от одит на сигурността, за да се гарантира възможност за проследимост при въвеждането на кода в производствена среда в компании от финансовия сектор. Проследяването гарантира отчетността, за да помогне за защита срещу някакви хора, които правят лоши неща в системата – и помага да проследим тези хора, ако нещо „странно” вземе да се случва. Това е един изцяло основателен повод за одит. Това е въпросът „Защо?”, който ние трябва да разберем.
Въпросното разбиране може да ни помогне да се измъкнем от заплетените процеси, АКО предложим рационални алтернативи. „Да, ние можем да преминем към напълно автоматизиран цикъл на изграждане и внедряване, дори и в производството. Ние ще имаме нужда от артефакти, които доказват, че само изграден и тестван код бива въведен в цялата среда, и ние ще можем да проследим назад във времето всеки ред код – поради тази именно причина”.
Говорите за „срещи… които задушават… продуктивността”. Добре, но това е често срещан проблем за доста организации, далеч не само в софтуерната индустрия. Защо се случва така?
А кое е причината за гадните срещи? Много от същите фактори, които създават „усложнени” процеси! Не е лесно това да се промени, но всеки човек в организацията може да предприеме някои стъпки, за да помогне за промяната. Например, поискайте промяна на календара за срещи в организацията, така че по подразбиране срещите да са 15 минути, вместо 30 минути. Всички във фирмата могат да дадат конкретни предложения, за да помогнат да се промени корпоративната култура на компанията.
Случва ли ви се да имате многочасови заседания без дневен ред? Това са мързеливи, неуважително губещи времето на всекиго срещи! Учтиво заявете на организатора на срещата нещо от типа на „…наближавам крайния срок на работата по следващата версия и тази покана за среща не ми дава достатъчно информация, за да разбера защо трябва да спра работата си. Можете ли да съкратите срещата и да изпратите ясен дневен ред, така че да разбера какво търсите?”
Случва ли се срещите да се превърнат в дълъг, детайлен разговор за статуса на едва двама-трима души в залата, пълна с членове на екипа? Две неща могат да помогнат тук. Първо, предлагам колективния подход „изправи се и кажи”. В този формат на среща всеки човек става и обсъжда това, което е направил вчера, това, по което работи днес, и нещата, които са го затруднили. Походът помага да се намали чопленето по всяка отделна задача – включително много такива, по които изобщо не се работи. Освен това форматът позволява споделяне на информация с другите в екипа, а не просто докладване.
На второ място, насърчавайте задълбочените, детайлизирани дискусии да се изместват встрани от основната. Например: „Това е важна тема и изглежда вие двамата имате идеи какво може да се направи. Можете ли да се видите след срещата ни и да си изясните тези подробности?” Този подход може да бъде приложен, с необходимата доза уважение, от всекиго в срещата. И ще откриете, че като цяло много добре се приема от другите в стаята!
Аз лично съм използвал тези техники, за да помогна за значително подобряване на организационната култура на срещите в няколко компании, малки и големи. В началото може да е странно, но гледам да намеря съюзници, които да помогнат с подкрепата си и да започнат да изразяват собствените си възражения по отношение на „черната дупка” на непродуктивните срещи.