![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovДискуссии про то, что можно, а что нельзя сделать определенным техническими средствами очень часто скатываются в унылый срач, в котором стороны по кругу повторяют одно и то же из-за того, что:
1)Технические проблемы обсуждаются на уровне самой простой возможной реализации
2)Фичи и возможности обсуждаются на уровне навороченного сервиса или коммерческого продукта
3)Разрыв в сложности и требованиях к качеству между (1) и (2) одной из сторон напрочь игнорируются.
Чем меньше человек шарит в обсуждаемом, тем больший разрыв между (1) и (2) у него получается, и тем охотнее он его игнорирует.
Что я имею в виду? Перефразируя "Мистический человеко-месяц" Брукса (см. напрмер раздел Tar pit вот тут), разные уровни сложности технического решения можно описать вот так:
Накодили: мы делаем что-то один раз "на колене".
Превратили в практику: мы можем повторить свой успех "на колене" много раз.
Сделали сервис: мы формализовали наш опыт и отгородились от ошибок. Спецификации на исходные данные и результат. Контроль потребления ресурсов.
Сделали продукт: может использоваться человеком с минимальной квалификацией. Документирован. Протестирован. Интегрирован.
(это одна из возможных классификаций, не претендующая на роль единственной истинной)
Время и усилия, необходимые на внедрение каждого следующего уровня, многократно возрастают. Чтобы сделать что-то быстро на колене, может уйти N (часов, дней, ...). На то, чтобы сделать этот успех повторяемым, понадобится в 3-10 раз больше времени и сил. На программный сервис - еще больше. На продукт - на порядки больше.
Этот грустный аспект всегда учитывается при рассчете потенциальной отдачи - стоит ли тратить столько-то времени и сил? Какого качества результат мы получим? Оправдывает ли выхлоп усилия? Какой угодно (точнее - best-effort) результат может быть приемлимым или оправданным при однократной деятельности, но если мы ставим что-то на поток - то best effort уже явно недостаточен, более того - он может быть вреден. Типичный пример - изымание жидкостей на входе в самолет, повсеместно практикуемое сейчас.
Попробую проиллюстрировать сказанное на примере из предыдущего поста.
Оповестить тех, кто находится в зоне (предполагаемого) стихийного бедствия используя возможности мобильной связи.
Пришла беда, а никакой системы оповещения нет. Допустим, кто-то деятельный из МЧС связывается с оператором и просит помочь. Оператору не пофиг, и происходит что-то такое:
* Кто-то решает: "давайте разошлем СМС!" (для обсуждения именно СМС как средства оповещения есть другой пост).
* Радиопланирование берет зону на карте и выдает базовые, которые ее покрывают
* Эксплуатация базовой сети берет базовые и выдает TMSI/MSISDN тех, кто там делал location update
* Кто-то дает текст SMS
* Эксплуатация сервисных платформ осуществляет рассылку SMS
При этом самым главным элементом процесса будет какой-то технически подкованный сотрудник, который при помощи sed, grep, sql и такой-то матери "заинтегрирует" все этапы процесса: например, возьмет XML, который умеет экспортировать система радиопланеров и выберет оттуда идентификаторы базовых в виде, понятном эксплуатации базовой сети. Возьмет список MSISDN и отделит абонентов других "домашних сетей" (но оставит роумеров). Набросает скрипт, сующий SMS-ы в SMS-центр. Побъет список рассылки на куски, если надо. Посидит рядом, пока он расыслается, устраняя возникающие проблемы.
Каждый шаг сам по себе технически не сложен, но на стыковку и координацию участников уйдет уйма времени и сил. Будет много ошибок, но поскольку на каждом шаге доступны специалисты узкого профиля, они будут оперативно устранятся.
Весь процесс идет в режиме best effort - если получилось, то хорошо; если не получилось - ну, по крайней мере мы старались. При наличии умных инициативных людей на местах реально все сделать за 3-6 часов (большая часть времени уйдет на ожидание и синхронизацию участников). Но вполне реально, что может не повезти - где-то новичок чего-то не знает, где-то кто-то в отгуле и т.п.
После первого успеха вместо того, чтобы строить нормальную систему оповещения, кто-то решает "ну, в прошлый же раз как-то справились? давайте так и делать". И вот Оператору вменено в обязанность осуществлять подобные рассылки. Деятельность, описанная выше, становится частью должностных инструкций. Оператор следит за тем, чтобы люди с нужными знаниями были доступны (не ушли вместе в отпуск, имели дублера и т.п.). Новые сотрудники обучаются необходимым навыкам. Вовлеченные технические специалисты пишут на колене скрипты, облегчающие им жизнь (определяющие и устраняющие типичные ошибки). Время от времени проводятся тестовые рассылки. При необходимости (и при возможности) у поставщиков железа заказываются дополнительные API и лицензии.
Технические сложности по-прежнему сглаживаются тем, что в процессе непосредственно участвуют узкие специалисты. Появляется ряд организацонных сложностей, они кодифицируются (преврщаются в процедуры и проч.).
Best effort уже недостаточно. Оператор гарантирует (или его обязывают гарантировать) определенный уровень сервиса - скорость, объем рассылки, время реакции и т.п.
Чтобы создать и отладить этот процесс, потребуется, допустим, 2-6 месяцев (не в последнюю очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
После пары факапов или чтобы разгрузить людей Оператор создает или покупает систему, у которой есть API, позволяющее делать такие рассылки сравнительно небольшими усилиями. Одному-двум сотрудникам поручена ее эскплуатация. Система умеет фильтровать большинство типичных ошибок (кривые номера телефонов, сбои при доставке, ...) и ведет себя пристойно с точки зрения потребления разных ограниченных ресурсов (нагрузка на SMS, HLR/VLR, ...).
Чтобы сделать спецификацию на такую систему, разработать или купить и интегрировать ее, потребуется, допустим, 6-12 месяцев (в первую очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
Сотрудник МЧС может выделить мышкой область на карте, ввести текст СМС, после чего произойдет рассылка, а он в реальном времени будет видеть ее ход.
Для этого государство в лице МЧС выбирает поставщика (не надо смеяться :), который говорит "СМС-ы?! Да вы все упоролись!" и выкатывает спеку на, допустим, сервис на основе cell broadcast + специфического sim toolkit. Потом поставщик интегрируется с операторами, операторы потихоньку меняют абонентам сим-карты (или через OTA обновляют toolkit), и сервис запускается. Если есть в принципе доступна - сервис будет работать и информировать всех, у кого включен телефон (т.е. качество будет максимально возможным для данной технологии).
Чтобы все это интегрировать и внедрить нужно 6-24 месяцев.
Какие можно из этого сделать выводы?
Рассуждения вида "ну, можно было бы все равно разослать СМС-ы - даже если бы 10% дошло, все равно было бы хорошо" - это best effort, и это справедливо только в случае "пришла беда, откуда не ждали, и мы делаем все возможное и невозможное, чтобы спасти ситуацию". Если же риск или потребность прогнизируемы (а система оповещения, очевидно, необходима), если это не одноразовая работа (а система оповещения, очевидно, не одноразова), то best effort никуда не годится (тем более что есть гораздо более надежные или простые или дешевые альтернативы: cell broadcast, машины с матюгальником, радиоточки, ...).
Да, СМС может быть вспомогательным средством (наряду с фейсбуком, твиттером и прочими слабо подходящими средствами) в какой-то 10 или 15 версии сервиса, но при отсутствии альтернатвных надежных методов слова "оповещение населения" и "СМС" не должны стоять в одном предложении. Усилия надо тратить на что-то реально полезное, а не на фигню.
Just saying.
1)Технические проблемы обсуждаются на уровне самой простой возможной реализации
2)Фичи и возможности обсуждаются на уровне навороченного сервиса или коммерческого продукта
3)Разрыв в сложности и требованиях к качеству между (1) и (2) одной из сторон напрочь игнорируются.
Чем меньше человек шарит в обсуждаемом, тем больший разрыв между (1) и (2) у него получается, и тем охотнее он его игнорирует.
Что я имею в виду? Перефразируя "Мистический человеко-месяц" Брукса (см. напрмер раздел Tar pit вот тут), разные уровни сложности технического решения можно описать вот так:
Накодили: мы делаем что-то один раз "на колене".
Превратили в практику: мы можем повторить свой успех "на колене" много раз.
Сделали сервис: мы формализовали наш опыт и отгородились от ошибок. Спецификации на исходные данные и результат. Контроль потребления ресурсов.
Сделали продукт: может использоваться человеком с минимальной квалификацией. Документирован. Протестирован. Интегрирован.
(это одна из возможных классификаций, не претендующая на роль единственной истинной)
Время и усилия, необходимые на внедрение каждого следующего уровня, многократно возрастают. Чтобы сделать что-то быстро на колене, может уйти N (часов, дней, ...). На то, чтобы сделать этот успех повторяемым, понадобится в 3-10 раз больше времени и сил. На программный сервис - еще больше. На продукт - на порядки больше.
Этот грустный аспект всегда учитывается при рассчете потенциальной отдачи - стоит ли тратить столько-то времени и сил? Какого качества результат мы получим? Оправдывает ли выхлоп усилия? Какой угодно (точнее - best-effort) результат может быть приемлимым или оправданным при однократной деятельности, но если мы ставим что-то на поток - то best effort уже явно недостаточен, более того - он может быть вреден. Типичный пример - изымание жидкостей на входе в самолет, повсеместно практикуемое сейчас.
Попробую проиллюстрировать сказанное на примере из предыдущего поста.
Задача
Оповестить тех, кто находится в зоне (предполагаемого) стихийного бедствия используя возможности мобильной связи.
"Накодили"
Пришла беда, а никакой системы оповещения нет. Допустим, кто-то деятельный из МЧС связывается с оператором и просит помочь. Оператору не пофиг, и происходит что-то такое:
* Кто-то решает: "давайте разошлем СМС!" (для обсуждения именно СМС как средства оповещения есть другой пост).
* Радиопланирование берет зону на карте и выдает базовые, которые ее покрывают
* Эксплуатация базовой сети берет базовые и выдает TMSI/MSISDN тех, кто там делал location update
* Кто-то дает текст SMS
* Эксплуатация сервисных платформ осуществляет рассылку SMS
При этом самым главным элементом процесса будет какой-то технически подкованный сотрудник, который при помощи sed, grep, sql и такой-то матери "заинтегрирует" все этапы процесса: например, возьмет XML, который умеет экспортировать система радиопланеров и выберет оттуда идентификаторы базовых в виде, понятном эксплуатации базовой сети. Возьмет список MSISDN и отделит абонентов других "домашних сетей" (но оставит роумеров). Набросает скрипт, сующий SMS-ы в SMS-центр. Побъет список рассылки на куски, если надо. Посидит рядом, пока он расыслается, устраняя возникающие проблемы.
Каждый шаг сам по себе технически не сложен, но на стыковку и координацию участников уйдет уйма времени и сил. Будет много ошибок, но поскольку на каждом шаге доступны специалисты узкого профиля, они будут оперативно устранятся.
Весь процесс идет в режиме best effort - если получилось, то хорошо; если не получилось - ну, по крайней мере мы старались. При наличии умных инициативных людей на местах реально все сделать за 3-6 часов (большая часть времени уйдет на ожидание и синхронизацию участников). Но вполне реально, что может не повезти - где-то новичок чего-то не знает, где-то кто-то в отгуле и т.п.
"Сделали процедуру"
После первого успеха вместо того, чтобы строить нормальную систему оповещения, кто-то решает "ну, в прошлый же раз как-то справились? давайте так и делать". И вот Оператору вменено в обязанность осуществлять подобные рассылки. Деятельность, описанная выше, становится частью должностных инструкций. Оператор следит за тем, чтобы люди с нужными знаниями были доступны (не ушли вместе в отпуск, имели дублера и т.п.). Новые сотрудники обучаются необходимым навыкам. Вовлеченные технические специалисты пишут на колене скрипты, облегчающие им жизнь (определяющие и устраняющие типичные ошибки). Время от времени проводятся тестовые рассылки. При необходимости (и при возможности) у поставщиков железа заказываются дополнительные API и лицензии.
Технические сложности по-прежнему сглаживаются тем, что в процессе непосредственно участвуют узкие специалисты. Появляется ряд организацонных сложностей, они кодифицируются (преврщаются в процедуры и проч.).
Best effort уже недостаточно. Оператор гарантирует (или его обязывают гарантировать) определенный уровень сервиса - скорость, объем рассылки, время реакции и т.п.
Чтобы создать и отладить этот процесс, потребуется, допустим, 2-6 месяцев (не в последнюю очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
"Сделали сервис"
После пары факапов или чтобы разгрузить людей Оператор создает или покупает систему, у которой есть API, позволяющее делать такие рассылки сравнительно небольшими усилиями. Одному-двум сотрудникам поручена ее эскплуатация. Система умеет фильтровать большинство типичных ошибок (кривые номера телефонов, сбои при доставке, ...) и ведет себя пристойно с точки зрения потребления разных ограниченных ресурсов (нагрузка на SMS, HLR/VLR, ...).
Чтобы сделать спецификацию на такую систему, разработать или купить и интегрировать ее, потребуется, допустим, 6-12 месяцев (в первую очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
"Продукт"
Сотрудник МЧС может выделить мышкой область на карте, ввести текст СМС, после чего произойдет рассылка, а он в реальном времени будет видеть ее ход.
Для этого государство в лице МЧС выбирает поставщика (не надо смеяться :), который говорит "СМС-ы?! Да вы все упоролись!" и выкатывает спеку на, допустим, сервис на основе cell broadcast + специфического sim toolkit. Потом поставщик интегрируется с операторами, операторы потихоньку меняют абонентам сим-карты (или через OTA обновляют toolkit), и сервис запускается. Если есть в принципе доступна - сервис будет работать и информировать всех, у кого включен телефон (т.е. качество будет максимально возможным для данной технологии).
Чтобы все это интегрировать и внедрить нужно 6-24 месяцев.
Какие можно из этого сделать выводы?
Рассуждения вида "ну, можно было бы все равно разослать СМС-ы - даже если бы 10% дошло, все равно было бы хорошо" - это best effort, и это справедливо только в случае "пришла беда, откуда не ждали, и мы делаем все возможное и невозможное, чтобы спасти ситуацию". Если же риск или потребность прогнизируемы (а система оповещения, очевидно, необходима), если это не одноразовая работа (а система оповещения, очевидно, не одноразова), то best effort никуда не годится (тем более что есть гораздо более надежные или простые или дешевые альтернативы: cell broadcast, машины с матюгальником, радиоточки, ...).
Да, СМС может быть вспомогательным средством (наряду с фейсбуком, твиттером и прочими слабо подходящими средствами) в какой-то 10 или 15 версии сервиса, но при отсутствии альтернатвных надежных методов слова "оповещение населения" и "СМС" не должны стоять в одном предложении. Усилия надо тратить на что-то реально полезное, а не на фигню.
Just saying.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2012-07-11 11:23 am (UTC)(no subject)
Date: 2012-07-11 11:43 am (UTC)(no subject)
Date: 2012-07-11 12:43 pm (UTC)(no subject)
Date: 2012-07-11 12:47 pm (UTC)Но по сути именно это и нужно - чтобы матюгальники врубались по команде на всей опасной территории и с нужным текстом, а в остальное время молчали. Проект по-любому убыточный.
(no subject)
Date: 2012-07-11 03:16 pm (UTC)(no subject)
Date: 2012-07-11 06:35 pm (UTC)(no subject)
Date: 2012-07-12 12:02 am (UTC)(no subject)
Date: 2012-07-12 10:44 am (UTC)(no subject)
Date: 2012-07-13 06:57 pm (UTC)Была аппаратура П-160/164/166 с огромной номенклатурой изделий для организации всего-всего касаемо оповещения на разных уровнях.
Первая попавшаяся цитата про систему:
(no subject)
Date: 2012-07-13 10:49 pm (UTC)(no subject)
Date: 2012-07-13 10:54 pm (UTC)(no subject)
Date: 2012-07-11 01:19 pm (UTC)Ерунда, значит всего лишь надо удалённо их включить, ггг!
(no subject)
Date: 2012-07-11 01:20 pm (UTC)(no subject)
Date: 2012-07-11 03:27 pm (UTC)