4 признака дисфункции в айтишной команде

16 комментариев
4 признака дисфункции в айтишной команде

Если поработать в ИТ-индустрии с десяток лет, то уже интуитивно улавливаешь, когда ситуация на проекте начинает выходить из-под контроля. Если же такое чутье у вас пока отсутствует – обратите внимание на следующие моменты, которые можно считать первыми тревожными звоночками. 

Подробнее о нюансах

1. Все зависит от того…

Если спрашиваешь сотрудника, как работает тот или иной компонент, или где находятся определенные данные, он пускается в объяснения, которые начинаются с фразы «Всё зависит от того…»

Например, я спрашиваю, как проверяется пользовательский пароль, а сотрудник выдает мне что-нибудь вроде: «Все зависит от того, зарегистрировался ли пользователь до 2001 года. Если так, то нужно вызвать систему genesis logon, а после 2001 мы уже переключились на active directory. Но это если пользователь не был клиентом той компании, что мы купили в 2005. В таком случае, нужно вызвать «миграционный» протокол LDAP, который они тогда прикрутили. Этот протокол использует Netscape LDAP, поэтому понадобится библиотека JNDI, кстати, мы ее пропатчили, чтобы справиться с некоторыми багами. Ну а если пользователь – админ, то мы храним его учетную информацию в базе данных по персоналу. Чтобы достать данные оттуда, нужно выполнить поиск по ODBC».

Все понятно: накопился технический долг, неэффективные решения никто не дорабатывал, а вот теперь длинный список «всё зависит от того…» 

2. Вася Пупкин

Здесь речь пойдет о системе или компоненте, в которой разбирается только один человек. Такую ситуацию можно было бы саркастически назвать «ипотечно-ориентированное программирование» (кодим, пока не отбит кредит за квартиру), но иногда она возникает из-за банальной апатии. К сожалению, некоторые системы кажутся такими скучными, что работать над ними никто не желает, так что ее просто забрасывают, полностью пренебрегая всякой техподдержкой. Сложности начинаются всякий раз, когда «эту задачу может решить только Вася Пупкин», а на деле оказывается, что и Вася-то уже с трудом представляет себе систему. Он может выполнять лишь минимальную работу, чтобы она хоть как-то фурычила.

На самом деле подобные проблемы возникают лишь с теми старыми системами, которые по-прежнему важны для организации. В противном случае старую систему можно просто отключить. Но если она решает конкретные задачи, то весьма вероятно, что рано или поздно ее придется усовершенствовать, а сделать этого никто не сможет – Вася-то давно уволился.

3. Супергерой

Такая проблема с поддержкой во многом перекликается с предыдущей, но речь уже идет не о том, что система отказала, а о том, насколько катастрофическими последствиями это чревато… Как вы понимаете, последствия всегда катастрофические. Если система отбилась от рук, то мы вспоминаем, что спасти нас может лишь один толковый парень – наш местный супергерой. Разумеется, когда случилось ЧП – его рядом нет, но все знают, что лишь он способен все исправить. 

Когда случается катастрофа, мы лихорадочно пытаемся с ним связаться: звоним на домашний, на мобильный, стучим в Твиттер. Его нигде нет. Что делать? Мы обречены. Казалось бы, все пропало, и тут… дозвонились! Героя нашли, но он сейчас на пляже в Рио. Выйти в сеть и оценить ситуацию он не может. Однако он не теряется: можно по частной виртуальной сети подключиться к серверу в Гамбурге, создать SSH-туннель через датацентр в Сан-Франциско, а оттуда выйти на корпоративный сетевой экран… и вот, он уже здесь! Всего за несколько минут умелец диагностирует потенциальную проблему. Людей вызывают на командный пункт, раздаются приказы, бюрократия игнорируется, изменения делаются по-быстрому. Наконец, наш герой объясняет суть проблемы, говорит, что все сложно, потребуется время, но он эту задачу решить сможет. Никто, в общем-то, не представляет, о чем он толкует. За полночь систему удается реанимировать, все хлопают друг друга по плечам – мы команда, мы выдюжили! Но, самое главное, в ножки кланяемся нашему герою. Эх, что бы мы без него делали…

Все благодарят спасителя, а потом забывают о нем примерно на месяц, ровно до того момента, когда вновь случается такая же катастрофа. Проблемы в таких системах так и не удается окончательно исправить. Может быть потому что команда техподдержки не обладает для этого достаточной квалификацией, либо просто не имеет на это времени – слишком занята, не до подвигов.

4. Канцерогенный прототип

Такая система начинается с классной идеи, обладающей большим потенциалом. Для оценки потенциала создается демо-версия/пилотная версия/прототип, и складывается впечатление, что потенциал вполне понятен. Компания с энтузиазмом запускает проект в производство – руководство уже строит наполеоновские планы. Инженеры, реализовавшие прототип, конечно, польщены такой высокой оценкой своей работы, однако остаются сдержанными – ведь это всего лишь демо-версия. 

Технари четко говорят об этом команде. Система еще нежизнеспособна, она плохо масштабируется, в ней еще нужно доделать механизм обработки исключений, журналирование отсутствует, мониторинг хромает и т.д., и т.п. Однако никто к ним не прислушивается, начальство просто обещает «попозже» выделить команде время на всю эту доработку.

«Попозже» так и не наступает. Система пошла в работу, поэтому постоянно приходится добавлять новые фичи. Она стремительно растет и уже начинает влиять на работу других систем. К сожалению, из-за многочисленных шероховатостей добавление новых возможностей протекает неаккуратно, технический долг накапливается.

Решение 

Как и большинство проблем в ИТ-сфере, технические проблемы обусловлены ошибками управления. Все вышеперечисленные симптомы возникают из-за ряда проблем менеджмента. Однако, корень любой проблемы – это нежелание менять статус-кво, повышать качество разработки и брать ситуацию под контроль. Определите, какой уровень качества является для вас минимально приемлемым, и не опускайтесь ниже него.

Источник: Энди Хеджес

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Читайте также

Вакансии для Python-разработчиков на jobs.dev.by
Вакансии для Python-разработчиков на jobs.dev.by

Вакансии для Python-разработчиков на jobs.dev.by

Айтишников уволили за месяц больше, чем взяли на работу. Впервые за год+
Айтишников уволили за месяц больше, чем взяли на работу. Впервые за год+

Айтишников уволили за месяц больше, чем взяли на работу. Впервые за год+

ИТ-компании в апреле уволили почти тысячу человек, следует из данных Белстата (данные не учитывают микроорганизации и малые предприятия без ведомственной подчиненности — до 100 человек). Это «рекорд» за последние почти полтора года. Кроме того, впервые с января прошлого года уволенных за месяц айтишников оказалось больше, чем принятых на работу.
16 комментариев
Вакансии для автоматизаторов на jobs.dev.by
Вакансии для автоматизаторов на jobs.dev.by

Вакансии для автоматизаторов на jobs.dev.by

Выплывут не все. Главные факты про то, как коронавирус изменил рынок труда
Выплывут не все. Главные факты про то, как коронавирус изменил рынок труда

Выплывут не все. Главные факты про то, как коронавирус изменил рынок труда

dev.by прочитал десятки статей и отчетов про то, как пандемия и кризис меняют и будут менять рынок труда — во всех отраслях и в ИТ в частности.
19 комментариев

Обсуждение

0

в точку)

0

Не только в IT, а везде проблемы обусловлены ошибками управления. Веть если бы над каждым разработчиком поставить манагера, котоый подскажет, что пароль надо проверять не "в зависимости от того как..." а методом CheckPassword, то наступит рай. А если к каждой доярке или механизатору приставить по Александру Рыгоровичу, то успехи СХ наверняка ошеломят даже видавших виды аграриев...

Но я так и не понял, какое же есть универсальное решение... Ну решили, что уровень качества должны поставить высочайший, ну а дальше? Удвоить штат манагеров, утроить? Ну что бы к каждому Васе или Супергерою приставить, дабы выведать эти сокральные знания: как поднять систему в случае сбоя, а лучше побудить Васю-Супергероя вместо кода написать пошаговую инструкцию на все случаи жизни.

0

А потом искать и Васю и менеджера? =D

1

Универсальное решение:
1) Не брать на работу кого попало
2) Выделять времени на проект столько, сколько нужно

В условиях аутсорсинга почти нереализуемо :)

-1

а в продуктовой компании времени завались??? бу-га-га.... да там со сроками в РАЗЫ жестче чем на аутсорсе!!

1

Дело не во времени, а в понимании того, что хорошие вещи не делаются на скорую руку, наспех набранными командами. В аутсорсе к этому просто чаще прибегают.

-1

в продуктах процент "хороших вещей" такой же как и в аутсорсе.

1

Ага, да.
А в книге "Adrenaline Junkies and Template Zombies" можно ещё штук 40 таких признаков найти :)

0

по поводу #1 - вы сами понимаете, что пишете бред? Как раз работаю с проектом, который выглядит примерно так из-за заказчика.

Anonymous
Anonymous embedded engineer в ИНДЕЛА
0

это всё не ошибки управления, это отсутствие архитектора проекта. когда пишут код, а потом документацию по нему. вместо того чтобы кодить то, что описано в заранее разработанном документе.

0

Отсутствие архитектора не ошибка управления? ))

1

"в заранее разработанном документе."
Анекдот:
стартап по заранее разработанным документам.

Anonymous
Anonymous Senior Java Developer в Toptal
0

Отсутствие архитектора проекта -- это, пожалуй, очень распространённая ошибка управления.
А подбор хорошего архитектора -- звучит как универсальное решение. Но только это решение должно быть тоже качественно исполнено. :)

На самом деле универсальное решение -- это в принципе качественный подбор кадров под конкретный проект. А с другой стороны, хорошего архитектора-то как раз и имеет смысл вовлекать в этот процесс.

Anonymous
Anonymous ломаю стены головой в Aitoc
1

А тут вообще весело:
http://en.wikipedia.org/wiki/Anti-pattern

Anonymous
Anonymous Senior Java Developer в Toptal
0

«Кадры решают всё»
~ Сталин

ИТОГО: Чтобы был хороший продукт, заниматься надо не продуктом, а кадрами, которые этот продукт сделают.
Должно быть очевидно, что кадровики и менеджеры -- тоже кадры.

Эта хорошая статья, как я понимаю, направлена на повышение грамотности менеджеров, а также на разъяснение ситуации инженерам, которые должны уметь иденцифицировать плохих менеджеров и уметь доводить сложившуюся ситуацию как риск наверх (и возможно самим становиться менеджерами). Но наверху тоже может быть пофик, либо сама бизнес модель компании может не предполагать качественный кадровый состав. Хороший инженер должен понимать бизнес модель, на которую он работает (и целесообразно выбирать себе песочницу для жизни :-) ).

0

>> 4. Канцерогенный прототип
вот это в той или иной степени встречается почти всегда)

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже