Дмитрий Волошин - Образованец в большом городе. Записки о жизни в бизнесе и корпорациях

Или обратная ситуация. Делаем систему управления предприятием: продажа, производство, сервис, экономика и легонький такой управленческий учет. Так сказать, full custom SAP Light на C++. Идем от исследований. Все как полагается, модель as is, модель to be, туча use cases, от UML рябит в глазах. Кстати, вы видели когда-нибудь «красного директора» оборонного предприятия, который на совещании с топ-менеджментом обсуждает business use case системы? А вот я видел: душераздирающее, доложу вам, зрелище. И вот в какой-то момент этого анализа заказчик становится совсем несчастным. Нет, все хорошо, все правильно, мы тщательно и с криками выявляем его потребности и ожидания. Его, прости господи, key needs. Но он пощупать уже что-то хочет. Хотя бы документооборот. Хотя бы между ним и его помощником. А не этот анализ «в космосе».

Обратите внимание: и в первом, и во втором случае заказчик несчастлив. Да, вы можете сказать, что команды были непрофессиональны. Да, вы можете сказать, что заказчик был «не созревший». Думаю, все так и было. Но лично в моей практике эта ситуация повторялась раз за разом. И когда речь шла о программных проектах, и организационных. Всегда шел рассинхрон между желанием сделать «все по уму» и потребностью «здесь и сейчас». И суровейшие кризисы в проектах были обусловлены этим рассинхроном. Проектная команда и заказчик смотрели друг на друга и друг от друга раздражались. Потому что если у проектной команды в голове методология и принцип do right right things, то у заказчика – его бабки и потраченное время. Согласитесь, есть почва для конфликта.

Я это к чему? Можно проектировать как угодно и нужно выбирать способ в зависимости от контекста и темперамента заказчика. Важно понимать, что и тот и другой метод подразумевает, что в голове или на бумаге есть big picture, образ результата программы или системы. И что это образ должен предельно одинаково отображаться в голове и на бумагах у заказчика и исполнителя. И что есть работающие методы синхронизации этого образа. Потому что он имеет обыкновение «расползаться» во времени. Ну так как аппетит растет во время еды, и «за время пути собачка смогла подрасти».

Есть третий способ. Он для очень опытных. Называется «все вдруг». Это когда проектирование и реализация идет со всех сторон, в том числе – и с середины. Очень сложный способ. Нервозатратный. Но, по моей практике, самый эффективный.

#выступление #любимоедело

Что такое идеальное выступление? Наверное, это то, после которого все слушавшие его начали что-то делать. Что-то новое для себя или что-то привычное, но с удвоенной энергией. Искать новые галактики, бозон Хиггса, плавать, бегать, учить. Или о чем-то новом думать, изучать, анализировать. Тоже близко к деланию, но почему-то часто считается другим видом активности.

И получается, что основным качеством, основным свойством хорошего выступления является способность заинтересовать. Простая формула: есть интерес – хорошее, нет интереса – вполне себе плохое выступление. А как понять, есть интерес или нет? Разные способы есть, задают ли вопросы, смеются. Сейчас самый верный способ – по количеству включенных телефонов или планшетов. Чем больше – тем менее интересно.

Меня интересует два вопроса: зачем выступать плохо и зачем приглашать плохих выступающих? И если второй вопрос имеет много ответов, то ответ на первый для меня совершенно непонятен. Не любишь выступать – не выступай. Надо выступить – готовься. Ведь это же навык, тренируемый навык. А значит, это просто вопрос усилий. Мы же не идем на переговоры без переводчика, если не знаем язык собеседника. Так зачем тогда выступать по бумажке?

Я думаю, это опять вопрос делания любимого дела. Ну представьте: вам не нравится то, чем вы занимаетесь. Мало того, что вы со стоном идете на работу, так вот еще и про это все надо рассказывать! Это же чистой воды издевательство над вашей самооценкой. Конечно, готовить спич не хочется. Само собой разумеется, что презентация делается в стиле «5 000 символов на страницу», меленько-меленько так. И получается, что зал зевает, сам себя не любишь, и зачем потратил несколько часов на дорогу, непонятно.

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

#agile #экологияотношений

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

И тут – бац! Agile! Это как империя наносит ответный удар. Было интересно посмотреть на это из партера. Во-первых, какое-то невероятное количество менеджеров стали обращаться с просьбой рассказать про это. Мое воображение потрясла очень взрослая дама лет 55—60 из одной ну очень консервативной компании. Она пришла с листочком и ручкой и тщательно записывала про agile. Правда, они все задавали странный, на мой вкус, вопрос: как реализуется agile в управлении? Когда это спросил один, два человека, я еще думал, что ослышался, но когда в течение пары месяцев это спросил десяток людей…

Честно, я не специалист. Последний раз я руководил командой full-custom-разработки лет 8—10 назад. За это время многое ушло вперед, я уверен. И у меня осталось стойкое ощущение, что выбор инструмента (а методика управления процессом разработки – это инструмент) важен, но он сильно зависит и от предметной области, и от особенностей заказчика, и от собранной команды. И еще мне казалось, что важность выбора этой методики стоит примерно на третьем-четвертом месте. Уверенно уступая подбору, мотивации, развитию членов творческого разработческого коллектива.

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

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