?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Почему ИТ-люди не должны решать проблемы бизнеса
psilonsk


Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник,
И дело не пойдет на лад.

И.Крылов

Возник тут недавно вопрос о том, как бизнесу правильно общаться с айтишниками и почему ИТ не выполняет задачи бизнеса. И вот что я думаю, друзья мои. Никак им общаться не надо. И задачи бизнеса выполнять не надо.

Тут в другом дело.

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

Прослойка между ИТ и бизнесом столь же необходима крупной компании, как собственная бухгалтерия. Без нее все быстро скатится в анархию и наколеночные разработки.

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

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

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

Что происходит с задачей дальше? На нее выделяется бюджет, открывается проект, назначается команда и менеджер, и пошло-поехало. Собственно, вся проектная деятельность в таких компаниях и держится на координации действий различных подразделений и на согласовании задач с заинтересованными бизнес-направлениями. Очень важный момент: задачу айтишникам ставят специально обученные аналитики, делая это по всем правилам аналитического искусства – четко и формально. И эти аналитики тоже не принадлежат ни к числу айтишников, ни, тем более, к числу заказчиков. Но именно они и объясняют ИТ-спецам, что от тех требуется, согласовав эту постановку и с маркетологами, и с дизайнерами, и с теми, кто обслуживает банкоматы, и с внешними поставщиками, и... в общем, вы поняли. )) Четко и формально.
И вот только тогда наступает звездный час айтишников, которые хорошо знают свое дело и умеют решать задачи, которые перед ними поставлены.

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

Как легко видеть, при таком подходе айтишник может встретить заказчика только в момент перерезания красной ленточки перед банкоматом. Ну, ладно, пусть повидаются на управляющем комитете по проекту. )

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

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

А чтобы пользоваться инструментом, мозгу нужна рука.



promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Это очень правильный подход, но он сродни сферическому коню в вакууме, к сожалению.

1. Как бы четко аналитики не поставили задачу, на стадии пилота (если хороший QA с привлечением конечных пользователей, то на стадии тестов) потребуется участие айтишников в "разборках" с конечными пользователями. Разумеется я не имею в виду, что программист будет с ними общаться, но архитектор или тим лидер - вполне. К сожалению, не всегда аналитик/интегратор/координатор может адекватно описать возникшую проблему.

2. В стадии постановки задачи (аналитиками) архитектор должен принимать непосредственное участие. Даже самые хорошие аналитики пропускают противоречия в требованиях заказчиков (я сейчас говорю о достаточно больших системах, на 50 и более человеколет разработки). Голова архитектора устроена иначе, чем у аналитика. Работая вместе они выявляют ошибки еще на стадии требований.

3. Определение размера бюджета желательно учесть мнение архитекторов - в моей практике случалось и что на элементарную (для айтишника) задачу выделялся многократный бюджет, и что на сложную задачу (но простую на взгляд бизнеса) выделялись копейки с соответствующим результатом в конце.

При всем при этом, сама идея "мухи отдельно, котлеты отдельно" и между ними кухарка (аналитики) - абсолютно правильна. Жаль только, что работать в похожей "среде" мне довелось лишь однажды.

Ага, вот несколько случаев из опыта.

1. Девочка-"аналитик" из иняна. Задача, по идее, разговаривать с заказчиками на их языке и согласовывать требования. Итог - три дня до сдачи, заказчики документацию не читали, "айти-люди" должы сидеть выходные и всё переделывать.

2. Та же девочка, отвлечённо умствуя, придумывает "мегаохуенную фичу". Ну, скажем, были красные кнопки. Давайте заебеним синие. Вопрос на полном серьёзе обсуждается с руководством, потом с заказчиками, и задание спускается "айти-людям". Те, увидев задание, охуеевают, потому что "мегаохуенная идея" высосана из пальца, а реалезация тянет за собой переделку половины проекта.

3. Заказчик-сумасшедший. В его интересах по максимуму тянуть резину, чтобы тянуть из клиентов деньги за обслуживание. Вместо совместного обсуждения проблемы (заказчик, его клиенты и "айти-люди") неделями тянется попарная переписка одних с другими. В итоге никто ничего не понимает, клиенты нервничают, заказчик довольно потирает руки.

4. Тот же "заказчик" в тех же целях затянуть процесс или по причине собственного идиотизма искажает информацию. Клиенты присылают жалобу на немецком, заказчик переводит на английский и высылает "айти-людям", перевирая вообще весь смысл. Хорошо ещё, что "айти-люди" в моём случае знали немецкий. Потом обратный процесс - ответ на английском, перевод на немецкий клиентам, опять враньё и согласование затягивается до бесконечности. При это страдают реальные люди, простаивает работа в больнице.

Вот зачем вся эта имитация деятельности? Чем сложне система, тем больше возоможностей у всяких подонков реализовывать свои скотские амбиции.

Выше ответил.

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

А как быть в небольшом холдинге, который перерос стартап, но до крупной компании как до китая пешком?

На 50 юзеров есть 2 админа и 1 программер, которые формально приписаны своему директору, но в реальности он ими не занимается, а занят своей организацией. Поэтому они получают задачи напрямую от юзеров и руководителей юзеров. Это постоянно приводит к конфликту интересов, админы загружены, но ничего не успевают. Попытки ранжировать приоритеты натыкаются на 2-3 задачи с нулевым приоритетом от разных подразделений. Постановка задачи юзером оставляет желать лучшего, он просит не то, что ему реально нужно, админ делает то, что понял он, результат - вообще хз что. Все недовольны.
Увеличить штат админов нет ресурсов, да и посадить некуда. Ввести должность диспетчера IT службы тоже не на что.
Что делать?

Видимо остается "громко кричать", требовать ресурсов, добирать людей и сажать их в коридоры.

Нет возможности строить нормальную систему - жить как раньше, ничего не поделаешь. Компания такая в итоге проиграет, конечно.

А нормальная это какая?
10 специалистов, директор, замдиректора, секретарша, диспетчер и снабженец?

Создать обслуживающую структуру, которая будет съедать половину прибыли?

Огромный минус всех без исключения "советов" и "инструкций" в том, что они подходят либо "ПБОЮЛу я да Марфа" либо Газпрому. А огромный пласт средних компаний в 50-100 человек остаются за бортом.

Если я правильно понял, ты за выделенный проектный офис, совмещающий в себе PM/BA функции. Это, в общем, хорошее решение. Но минусов и примеров, когда структура не работает тоже хватает.

1. Реализация его на практике как правило разбивается о вопрос компетентности. Чтобы выполнять функцию прослойки между IT и бизнесом, нужно разбираться как в IT так и в бизнесе, причем желательно в нужной области. В противном случае, прослойка оказывается неэффективной, и от нее в том или ином виде избавляются (а в худшем случае - она начинает тормозить проект).

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

2. Еще один минус такого подхода - зависимость от "ключевого" человека. В ситуации когда бизнес ПМ и IT PM работают вместе, они залезают в области друг друга и имеют общий контекст, поэтому в случае кризиса могут друг друга забэкапить. Появление эффективного человека-прослойки приводит к тому, что без него всё перестает работать.

3. Если на стороне подразделения-исполнителя (например IT) нет своего PMа, возникают проблемы с риск-менеджментом. Одна из задач PMа - знать, что происходит вокруг и может теоретически навредить проекту. В родном подразделении это реально, на уровней всей организации - практически невозможно.

PM, не владеющий контекстом, может, например, с удивлением узнать в середине проекта, что инфраструктурщики мигрировали все базы данных на новый MS SQL, поэтому нужно будет минимум сделать полный цикл регрессионного тестирования.

Точно так же и на бизнес-стороне - можно за месяц до релиза узнать, что в банке появился новый сегмент кредитных карт, и его тоже нужно поддерживать (а то что это интеграция с вообще другой платформой никого не волнует). Это, конечно, новые требования, но осдаочек-то у менеджмента останется.

4. Эта структура экономически неэффективна для небольших проектов. Если для проекта нужно 0.3 человеко-айтишника и 0.2 человеко-бизнеса, добавлять сюда человека-прослойку - увеличит и требования по ресурсам от IT/бизнеса (на координацию), и добавит, собственно, координатора. В итоге бюджет на маленькие проекты удваивается.

Существование того, что ты назвал "IT ПМ" - это вообще самое страшное, что может произойти. Точнее, пусть будет человек, отвечающий за то, что программеры работают и выдают работу в срок и в соответствии с критериями качества. Все остальное - не дело этого человека.
Я работал в компании, где текучка была высокой, но система работала.
Про неэффективность для малых задач - полностью согласен, для них обычно и ПМ н нужен.

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

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

Почему аналитики должны быть не в ИТ?

(Anonymous)
Аналитиков в бизнес-подразделении припашут делать что-то другое, не требования писать и не бизнес-процессы описывать

Re: Почему аналитики должны быть не в ИТ?

Нет.

Re: Почему аналитики должны быть не в ИТ?

(Anonymous)
Аналитиков в бизнес-подразделении припашут представлять интересы бизнеса перед разработчиками. А иначе - разработчики будут делать, что захотят и по факту подчинения заставлять аналитика это г.. впаривать бизнесу.

Сергей, не могу сказать, что категорически не согласен с представленным мнением )). Но, на мой взгляд, реальная картина несколько шире -- в рассмотренном примере, от силы, треть возможных задач IT.

Большая картина, на мой взгляд, очень хорошо отражена в книге "Что бизнес хочет от IT", которую я всегда горячо рекомендую )).

Ура, ты вернулся. )) Учитывая очередь на чтение, вряд ли доберусь до нее раньше февраля-марта. )

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

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

Все так, с одной поправкой - это не принципиально до тех пор, пока в дело не вступит политика. ) А как вступит, надо разделять. А она вступит, причем сразу. )

ну есть же над дизайнерами Арт-директор, так и над айтишниками должен быть АйТи-директор.. выполняющий свою менеджерскую функцию в сфере своей компетенции

Не понял вашу мысль, сорри.

Мне безумно нравится, как вы пишите) Спасибо. Очень интересно.

  • 1