aeshnik


Уменьшая скорость роста энтропии вселенной


Previous Entry Share Next Entry
Про Solution Selling и Systems Engineering: один кейс из практики
aeshnik
Моя работа часто заставляет меня выслушивать людей, понимать их видение решения проблемы (будем называть это, например, принятым способом работы), а потом объяснять им, что проблему решить можно в два раза быстрее и в два раза дешевле. Одновременно, без всяких компромиссов между "дешево" и "быстро". То есть, фактически мне приходится говорить людям, что они, читая какие-то свои книжки, получая информацию из уст более старших товарищей, еще что-то, привыкли делать всё не лучшим образом. Это на самом деле самая большая сложность. Вовсе не объяснить, что стоит в какое-то другое (как правило более раннее) время потратить больше денег и сил, чтобы потом не сесть в лужу (это будет потом). А сказать человеку, что он не прав, при этом найдя понимание.

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

Пришел к нам на встречу товарищ, который очень жестко ограничил доступное к изменению. Говорит, что есть у него изделие, которое ему нужно проверять. Это гидроцилиндр с цифровой системой управления. Он его проверяет таким же гидроцилиндром с такой же системой управления - стендом (это то, что собеседнику нужно разработать - его главная цель, его целевая система). И начальник сказал: вот вы напишите программу для системы управления стендом, а если я захочу гидроцилиндр в стенде поменять? А если я захочу другой гидроцилиндр протестировать? Что, мне опять вас ждать полгода, пока вы программу напишите? Отлично обозначенная проблема от начальника. И мой собеседник уже имеет решение: применить хитрый (на самом деле пригодный не для этого, но это не важно) метод в программе управления, который будет универсален для разных стендов, для разных тестируемых изделий. И делать эту программу собеседник мой будет не полгода, а три года, постоянно сдвигая сроки, потому что он ни разу такого не делал и не знает, реализуемо ли это вообще.
Рис. 1. Принятая структура системы.
Рис. 1. Как видит собеседник систему в начале встречи.

В принципе, продаванская сущность моей работы может сказать: "Продай ему то, что даст ему возможность ковыряться три года безрезультатно, не дергайся". Именно так, по идее, и стоило поступить. Но Дерек Хитчинс в книжке, на которую я уже ссылался, учит, что проблемы можно to solve (решать, прямо как решать уравнения), to resolve (разрешать, то есть находить достаточно хороший, удовлетворительный ответ) и to dissolve (отменять, то есть изменять ситуацию таким образом, что проблема исчезнет) - мой вольный перевод. Здесь собеседник не транслирует проблему начальника, но обозначает свою: "Мне бы сделать такую волшебную программу, которая бы ко всем изменениям адаптировалась". И можно, в принципе, брать и решать ее вот прямо так: благо, я могу дать ему инструменты, которые помогут ему бесконечно долго ваять эту программу. Собеседник удовлетворен, работодатель удовлетворен (он продал). Начальник собеседника не удовлетворен. Другие ребята на предприятии собеседника не удовлетворены. Да и сам собеседник, если подумать и поговорить с ним, такой перспективой тоже не будет удовлетворен. Но стоп! А причем здесь хотелки всех этих людей? А притом, что, как учит нас The Essence of Software Engineering (идеи которого легко экстраполируются на любые системы, не только software systems), если ты делаешь решение (solution), то тебе нужно думать не только про ту штуку, которую ты продаешь (или делаешь), но про то, какие к ней предъявляются требования. Которые, внезапно, возникают из-за того, что есть потребность в твоей штуке. Которая, внезапно, возникает из-за того, что есть люди (очень много людей, а не один decision maker, как учит Keith Eades в своей книжке про Solution Selling). И про все эти (и еще три другие) штуки неплохо бы думать, если ты вообще претендуешь на создание (или продажу) решения.

Но, что любопытно: про эти штуки можно думать вместе с собеседником! Тем самым, которому обычно так сложно объяснить, что он не прав. Отметив, что для плода его труда (я называю его целевой системой) есть требования, причем не столько его собственные, сколько требования начальника и других людей (которые просят стенд для тестирования своих устройств). Начинаем думать про них и вспоминаем, что настоящее требование - уменьшить и упростить переработки программы для каждого нового проекта (когда нужно вновь что-то тестировать стендом). А раз так, до давайте-ка попробуем расширить границы изменяемого в той системе, которую нужно произвести.
Рис. 2. Функциональная схема системы.
Рис. 2. Функциональная схема системы.

На рис. 2 можно найти функциональную схему (я привык называть это архитектурой, но, похоже, не все это одинаково понимают; даже коллега из INCOSE наморщил лоб, и пришлось договариваться о словах): из каких функциональных блоков система состоит и какие функциональные соединения имеет. Это на самом деле то, что нужно создать собеседнику. Ему будут давать разные тестируемые системы (это, похоже, всегда будут гидроцилиндры, но всегда разные). Они как-то будут соединяться с тестовым стендом (скорее всего, механически, но это не важно: важно, что нужно их соединять для обеспечения тестовых нагрузок). А стендом должен управлять человек. Ну а раз это (плюс сокращение затрат на разработку и переработку) настоящие требования, давайте попробуем подумать, как их можно удовлетворить тем, что есть у меня.

Рис. 3. Рекомендуемая структура системы.
Рис. 3. Рекомендуемая структура системы.

У меня есть только инструменты MATLAB\Simulink (чем богаты, что называется - дальше не будет лишних деталей про предлагаемую структуру, это не так интересно). Чтобы структурно не слишком усложнять стенд, предложено в один вычислительный блок (а мы договорились, что в стенде должен быть компьютер в любом случае: и систему управления надо делать, и результаты обрабатывать, и с человеком общаться) погрузить и функции системы управления, и захвата и обработки результатов. К такому вычислительному блоку предъявляются специальные инженерные требования: раз есть сопряжение с настоящей "железкой" (гидроцилиндром), то вычислительный блок должен работать в режиме реального времени. Чтобы удовлетворить требованиям начальника собеседника, собеседник получает среду, в которой может моделировать свою систему, сопряжение своей системы с тестируемой системой (без всяких, замечу, "железок": просто в виртуальной среде), разрабатывать на понятном себе языке алгоритмы управления, а потом переводить их для исполнения в машинный код.

Собеседник рад, что сможет делать свое дело без применения чуждых (относительно известных методов синтеза систем управления) языков программирования. Собеседник понимает, что для того, чтобы эта система (то, как он может разрабатывать) родилась, нужно исчерпывающе определить требования к такой системе руководителя, его коллег (штуки которых нужно тестировать) и уточнить предлагаемую систему работы (по Essence с точки зрения собеседника это Way of working; с моей точки зрения - это целевая система). Вуаля.

Вне рамок этого поста, но тоже интересно как-нибудь осветить:
- как в деталях работает предлагаемый стенд;
- как предлагается вести разработку такого стенда (жизненный цикл стенда);
- можно ли как-то предлагаемый способ разработки стенда применить к разработке тестируемой системы;
- нужна ли вся эта большая проработка задачи, или стоило остановиться на to solve (sic :)).

?

Log in

No account? Create an account