#проектирование #ожиданиязаказчика
#формулированиецелей
Когда я был программистом, в проектировании ПО было принято два подхода: снизу вверх и сверху вниз. Суть простая: сверху вниз мы от более абстрактных задач идем к менее абстрактным, анализируя общее и декомпозируя на частное, доходя до руды функций. В случае снизу вверх мы синтезируем, идем от частного к общему, в современных терминах проверяем гипотезы. Например: мы пишем систему управления заводом и начинаем разработку с драйвера обмена данными с конкретным оборудованием. В зависимости от того, как его удастся реализовать, меняется структура системы. Кстати, пример из практики.
Так вот, были сторонники того и другого подхода. О, сколько замечательных споров было на этот счет! А сколько прочитано книг! Это как эпическое сражение water flow и agile, почти как гендерные войны. И все никак не могли прийти к консенсусу: а что же лучше? Вот, скажем, система управления зданием. Сели, описали хотелки заказчика, исходя из них выбрали железо и написали (дописали) софт. Сдали. Заказчик счастлив? Нет, он как бы в целом доволен, но не очень понимает, для чего нужно все это в целом. То есть каждую функцию системы понимает, а как и для чего ему все это вместе нет. И, главное, отчего эти функции так взаимоувязаны. И отчего они такие именно у него. А все почему? Потому что на входе в проект он не был вовлечен в формулирование целей. Вернее, этого формулирования и не было. Шел синтез «в космосе».
Или обратная ситуация. Делаем систему управления предприятием: продажа, производство, сервис, экономика и легонький такой управленческий учет. Так сказать, 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! Это как империя наносит ответный удар. Было интересно посмотреть на это из партера. Во-первых, какое-то невероятное количество менеджеров стали обращаться с просьбой рассказать про это. Мое воображение потрясла очень взрослая дама лет 5560 из одной ну очень консервативной компании. Она пришла с листочком и ручкой и тщательно записывала про agile. Правда, они все задавали странный, на мой вкус, вопрос: как реализуется agile в управлении? Когда это спросил один, два человека, я еще думал, что ослышался, но когда в течение пары месяцев это спросил десяток людей
Честно, я не специалист. Последний раз я руководил командой full-custom-разработки лет 810 назад. За это время многое ушло вперед, я уверен. И у меня осталось стойкое ощущение, что выбор инструмента (а методика управления процессом разработки это инструмент) важен, но он сильно зависит и от предметной области, и от особенностей заказчика, и от собранной команды. И еще мне казалось, что важность выбора этой методики стоит примерно на третьем-четвертом месте. Уверенно уступая подбору, мотивации, развитию членов творческого разработческого коллектива.
С тех пор я часто слышу про agile в управлении. Скажу честно, мне пока никто не объяснил, что это за зверь. И зачем он нужен, и в чем его польза. Возможно, я просто не в тех кругах верчусь. Среди образованцев до этого пока не дошли. Но было бы весьма интересно, если бы кто-то рассказал. Потому что пока, ассоциативно и интуитивно, agile в управлении у меня в голове трансформируется в бардак. Особенно в областях, подразумевающих консервативный подход к принятию решений. Как представлю себе группу пожилых людей в костюмах, скандирующих, что люди и процессы важнее инструкций и инструментов, так дух захватывает от картинки.
P.S.: Мечта есть, возникла, пока писал. Вот если бы на отношения между людьми в коллективе, на экологичность отношений, на устранения неравенства общения, на демпфирование конфликтов, на ровный рабочий тон и прочее обращали бы сейчас столько же внимания, как на один из подходов к программной разработке. Вот была бы радость!
#какстолетназад #завтралучшечемвчера
Ночью читал статью про труд рабочих в дореволюционной России. Про 14-часовой рабочий день, про один выходной в месяц, про вредные производства и детский труд, про штрафы и невыплаты зарплат. Много интересного. И про бараки, и про торговлю продуктами с наценкой в счет выплачиваемой два раза в год зарплаты. Даже если половина в статье правда, то это лютый кошмар. Да, рентабельность фабрик достигала 45%. То есть деньги были.