“ози сайт използва бисквитки (cookies). јко желаете можете да научите повече тук. –азбрах

Ќовини »“ мениджмънт

9 начина, по които »“ мениджърите се самозалъгват

јко јхил беше »“ мениджър, самозаблудата щеше да бъде неговата јхилесова пета

от , 19 септември 2017 1 1162 прочитани€,

ъъъ



"ќ, каква мрежа преплитаме", казва шотландски€т писател ”олтър —кот, "когато се опитваме да заблудим н€кого." Ќо независимо от това, колко е заплетена мрежата, когато н€кой друг е целта, това е нищо в сравнение със ситуациите, в които се опитваме да заблудим себе си. » се заблуждаваме, че правим нещо - не защото умишлено искаме да си поставим грешни приоритети, да взимаме грешни решени€ и да преследваме неправилните цели, а защото самозаблудата е много по-лесна от това да гледаме реални€ св€т. ≈то девет често срещани ситуации, в които »“ мениджърите заблуждават не подчинените или колегите си в бизнеса, а себе си.

—амозаблуда 1: Ќие сме в крачка с бизнеса

"ѕриравн€ваме пон€ти€та »“ и бизнес" звучи като нещо велико и много »“ мениджъри създават сложни процеси за управление на сектора, за да се увер€т, че това се случва. Ќо това не е никак добре и много малък брой фирми прав€т този паралел със себе си. “е са по-скоро като семейство ёинг от сериала „ƒалас“, отколкото като „ѕерлите". ѕодобно приравн€ване обикновено се свежда до това да се умиротвор€ват политически играчи на власт или да се въвежда система за компенсации. »скате да сторнираме? ќ ! ўе сторнираме. »“ мениджърът влизат в рол€та на момче за всичко: ўе ви дадем каквото поискате, стига да финансирате проекта! — ревизии, »“ секторът може да не е в съответствие с бизнеса, но е съобразен с бизнес бюджета. јко това се съгласува и с бизнеса, всичко е добре, а ако не, това е проблем на н€кой друг.

—амозаблуда 2: ≈динствената причина за ъпгрейд на софтуера е когато новата верси€ носи важна бизнес стойност

“ова звучи не само убедително, но и като нещо, казано от опитен администратор. »“ мениджърът, който мисли така, е €сно насочен към бизнеса и не може да бъде обвин€ван в разходи за технологии заради самите технологии. “ози подход на пръв поглед дори способства за свиването на разходите за поддръжка на софтуера. »“ директорите, които приемат това мислене обаче, може би никога не са прежив€ли софтуерна или хардуерна катастрофа, или успешно са прехвърлили вината за бъркоти€та на н€кой друг. —офтуерните надстройки са превантивна поддръжка, за ко€то сами можете да прецените кога да платите – сега или по-късно. ѕо-късно обаче е много по-скъпо.

—амозаблуда 3: √олеми€т, важен за бизнеса проект изостава от графика? ўе стигнем следващата фаза и ще € свършим навреме

≈то обичайната прогреси€:  

»зисквани€ и спецификации: ‘азата за оценки на изисквани€та и спецификациите е мръсна работа.  олкото по-гол€м е проектът, толкова повече неизвестни се кри€т и вс€ка една от т€х усложн€ва нещата в следващите фази. ‘азата за оценка на изисквани€та и спецификациите винаги е дълга, но това е добре. ¬секи знае, че колкото по-задълбочена е първоначалната композици€ на проекта, толкова по-малко време ще отнеме след това процесът на кодиране и тестване.

ѕланиране: »“ секторът е съобразен с изисквани€та на бизнеса. ѕланирането върви от д€сно на л€во, започвайки с датата на доставка и работейки назад, независимо от графика, който ще постигне заложените цели. “ози път мениджърът на проекта, който иначе е изпаднал вече в отча€ние, мами и усуква, докато графикът изглежда приемлив, а изпълнението му навременно, стига никой да не се вгледа по-внимателно.

∆ълт: “ова е статутът на проекта, когато изостава чувствително от графика и то без възможност за наваксване, но има още достатъчно време преди крайни€ срок. ¬ този момент отричането все още замен€ реалността. –ъководителите на проекта Adroit, например, имат два подхода в подобни случаи. ѕърво, те натискат екипите да извършат тестове, което постав€ както проекта, така и екипа в статут „зелено“. ¬торо и особено важно, започват да си търс€т работа, преди просвалени€т проект да нанесе удар върху репутаци€та им.

ѕърво ниво тестове: “о се състои в охлаждане на първоначалната екзалтирана тържественост. — достатъчно занижени критерии и достатъчно знчимо вли€ние дори и най-лоши€т код може да се превърне в продукци€.

¬торо ниво тестове: »звестно е също като PROD. ¬инаги тествайте и то старателно. ≈динствени€т въпрос тук обаче е дали това задълбочено тестване е било проведено преди или след като софтуерът е вл€зъл в производство.

»звън релсите: Ќови€т »“ мениджър предотврат€ва катастрофата на влака, докато негови€т предшественик го обвин€ва. ¬ този момент ръководител€т на проекта посещава работните срещи със същото настроение, с което човек с проблеми с пиенето посещава сбирка на јнонимните алкохолици.

—амозаблуда 4: ѕравим ITIL (набор от добри практики за извършване на »“ услуги) 

“ова може да изглежда като семантично за€ждане, но н€ма такова нещо като "правене" на ITIL. ITIL е рамка, както нейните поддръжници търпеливо об€сн€ват на когото е склонен да слуша (като ц€ло това е една малка апатична аудитори€, ко€то не включва наши€ самозаблуждаващ се »“ мениджър). ITIL избро€ва нещата, в които един »“ специалист тр€бва да е добър, но не предписва как да един специалист да стане добър в т€х, което е добре, защото н€ма как да се направи списък, който да е адекватен и да работи във всички ситуации. (Ќе в€рвате? ѕомислете как бихте работили в малка рекламна агенци€. —ега помислете как бихте работили в гол€м правителствен подизпълнител, специализиран в киберсигурността.) ¬ допълнение към това, има много »“ мениджъри, които приравн€ват "правенето на ITIL" с удобно работещо обслужващо бюро (или поне преименуване на бюрото за помощ, така че да се чете "служба за обслужване"), а защо не и да се създаде консултативен съвет, който да седи между разработчиците на приложени€ (app dev) и »“ специалистите, така че и двете страни а да гледат в консултативни€ съвет, вместо един в друг.


gg


—амозаблуда 5. Ќие сме гъвкави

»ма »“ магазини, които са се преориентирали от "водопадните" техники за разработване на приложени€ към един или повече гъвкави варианти, или са в процес на това. Ќа всеки, който е приел този подход, веро€тно има дузина или повече, които вместо това, следват н€каква подобна форма, като се придържат стриктно към вс€ка от формалностите на —кръм, като напълно пренебрегват духа на гъвкавата трансформаци€. ѕоне половината от »“ магазините, които са успели да избегнат капана, са преминали в другата посока: ¬место системата Agile, са въвели Haphazard, убедени, че гъвкави€т подход е обречен на провал и готови да направ€т всичко възможно, за да се увер€т, че пророчеството им се изпълн€ва само.

—амозаблуда 6. Ќие правим devops

≈то какво добав€ devops към гъвкави€ микс: ѕърво, екипите които се занимават с разработките, включват »“ специалисти по чисто егоистични причини: “е не искат да чакат средата им да се изгражда и не искат да чакат тепърва да бъдат внедрени промени в софтуера. ¬торото е автоматизаци€ навс€къде, една наистина добра иде€. ∆еланието ръчно да се овладе€т софтуерните промени през техните отделни крачки е просто глупаво. “ретото е, че с devops, но не в най-гъвкавите варианти, софтуерът винаги е в състо€ние да се разгърне. Ќе, не, не, не, не. Ќе се оплаквам. —ред многобройните неудобни реализации на повечето гъвкави магазини, това означава, че Devops и Scrum не са напълно съвместими. Kanban работи по-добре. 

—амозаблуда 7: »маме култура за обслужване на клиенти

„уйте онези кикотени€, които идват от информационнитe отдели. “ова са отделите, които търгуват с тъпите истории на потребителите. “ова не е съставно качество на културата за обслужване на клиенти. ѕодобно качество е уважението. Ќо реално н€ма значение, защото ако имат култура на обслужването на клиентите, »“ мениджърите см€тат, че останалата част от бизнеса са техни клиенти, което е много лоша иде€. “ова води до създаването на недобре приспособими концепции, като например сторниране на плащани€ - чудесна възможност да си губите времето, енерги€та, а и доверие към вас. »“ директорите тр€бва да насърчават културата на обслужване. ј как могат да разберат дали имат такава в сво€та компани€ или не? јко все още слушате тъпи истории за потребители, значи н€мате такава.


mmm


—амозаблуда 8: Ќашата информационна сигурност е непоклатима

ѕомните ли пречките пред гъвкавостта и контролните списъци? ћного често, когато има контролен списък, той се използва за всичко, а не по предназначение - като начин за следене. »нформационната сигурност е обект на едно и също предизвикателство, особено когато е приложено сертифициране за съответствие. ћожем веднага да се сетим за PCI, стандарта за сигурност на платежните карти. ѕрипомнете си, че Target загуби около 40 милиона регистрирани клиентски данни през 2013 г., независимо от съответствието с PCI, и това далеч не е единствената загуба на данни от бизнеса, който е преминал н€каква форма на оценка на информационната си сигурност. јко »“ мениджърът см€та, че сигурността на информаци€та е напълно гарантирана, той веро€тно греши. Ћидерите в »“ сектора винаги се безпоко€т за информационната си сигурност, и приемат, че има н€какви дупки, които просто биха могли да бъдат в прилична форма.

—амозаблуда 9. Ќашите процеси на управление на »“ гарантират, че предприемаме само проекти с висока бизнес стойност

Ќека отново да се върнем към ц€лостното бизнес подравн€ване. »“ управлението тр€бва да гарантира само финансирането на проектите с най-висока стойност. » все пак, без значение колко добре е разработен процесът, той все още се изпълн€ва от едни и същи герои, които на първо м€сто не са "подравнени" един с друг. “ака че, освен оценката за стойността на всеки един бизнес проект, винаги има и доза €ростна злоба, свързана с окончателни€ набор от решени€. ƒобавете към това още един досаден детайл: ѕроекти, чи€то полза е намал€ване на разходите, ще имат предимство пред проекти, чи€то полза е увеличаването на приходите. «ащо? Ќамал€ването на разходите е под контрола на бизнеса. јко всичко върви според плана, разходите ще намале€т. Ќо увеличаването на приходите изисква клиентите да прав€т това, което искате да прав€т, а често те не го прав€т. ¬ие не можете да ги принудите. “р€бва да ги убедите. јко сте сигурни за всичко, то почти сигурно грешите. ј ако сте »“ мениджър и сте сигурен, че н€кое от тези девет изброени неща важи за вас, си задайте този прост въпрос: «ащо?

 ќћ≈Ќ“ј–» ќ“  

ѕолезни страници
    «а нас | јудитори€ | –еклама |  онтакти | ќбщи услови€ |
    ƒействителни собственици на насто€щото издание са »во √еоргиев ѕрокопиев и “еодор »ванов «ахов