Блог Александра Башкирова

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

проектирование

Подписаться на эту метку по RSS

Про процессы и исключения

Просмотров: 1446Комментарии: 0
Alib.spb.ru

Я тут подумал... Очень часто при описании бизнес-процессов описывая процесс как есть и особенно проектируя его как будет, аналитик забывает такую милую вещь, как исключения.

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

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

При этом наиболее печальная ситуация возникает на точке сходимости - то есть на руководителе.

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

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

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

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

Последнее, что стоит сказать: правила внедрить не так уж и сложно. Для этого достаточно иметь волю со стороны руководства. И да, для руководителей первого типа - отказаться от спасательства. А для руководителей второго типа - проявить жесткость.

Сложно? Да. Но оно в долгосрочной перспективе окупится.

Хабр: Что нужно учесть при проектировании системы, чтобы не было мучительно больно?

Просмотров: 1952Комментарии: 0
Alib.spb.ruРабота

На Хабре очережная интересная статья: "Что нужно учесть при проектировании системы, чтобы не было мучительно больно?". Статья о том, как много боли можно получить впоследствии, изначально - неверно спроектировав приложение.

Вернее, как "неверно спроектировав". Понятное дело, что когда гипотетическое веб-приложение типа "сайт с некоторыми функциями" делается "для себя" / "для 100 - 1000 пользоваталей", то по большому счету - не очень важно, "синхрон-асинхрон", "прямые права" (не через роли) и т.д. Когда пользователей становится 100 000 - 1 000 000 и выше, эти проблемы начинают "выстреливать", причем - в самый неожиданный момент. Да, кстати, это не только для веба - это в принципе, для многопользовательских приложений. У всех свои "пороги срабатываения проблемы", но то, что проблема "выстрелит" на больших объемах, если её оставить - 100%. Безальтернативно.

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

Так что мораль: если вы только начали проектировать приложение - думайте о росте. Если приложение уже есть, но в нем еще нет ни пользователей, ни данных - думайте о росте. Потому что если не думать, то "рост" заставит вспомнить о нем сам. И будет существенно больнее.

Если вам надо быстро нарисовать прототип мобильного приложения или веб-сайта...

Если вам надо быстро нарисовать прототип мобильного приложения или веб-сайта, то рекомендую воспользоваться проектом pencil.

Этот проект - это редактор, где можно достаточно быстро построить макет (прототип) интерфейса. Из интересного: редактор построен на движке Mozilla Gesko, соответственно, распространяется и как независимое приложение (linux, windows), и как... плагин для Firefox. Забавно :)

Штатно "из коробки" идет набор элементов, достаточный, чтобы отрисовать веб-приложение. Чтобы отрисовать, например, мобильное приложение - надо скачать соответствующий паки, и установить их.

Ссылки:

http://pencil.evolus.vn/ - сайт проекта. Строго говоря, именно этот проект "умер", и на смену ему пришло развтие проекта энтузиастами;

https://addons.mozilla.org/ru/firefox/addon/pencil/ - сайт аддона для Firefox. Отсюда его можно сразу установить в браузер;

https://code.google.com/archive/p/evoluspencil/downloads - сайт нового проекта. Отсюда можно взять как версии для win && lin, так и xpi - для firefox. Тут же, если поискать - отыщется и базовые элементы для отрисовки интерфейса Андроид;

https://code.google.com/archive/p/android-ui-utils/downloads - тут можно разжиться дополнительными элементами для отрисовки интерфейса Android;

Из плюшек. Приложение кроссплатформенное. В приложение интегрирован выход на OpenClipart - что есть "совсем хорошо". Ну и удобно... Например, такую картинку я накидал за пару минут буквально:

ну и скриншот:

Пост про то, как надо писать ТЗ

Периодически мне приходится в том или ином виде консультировать разные компании по поводу такого замечательного документа, как техническое задание на информационную систему.

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

Во-первых, всегда помнить - система, разрабатываетмая по ТЗ, автоматизирует процесс (напомню, речь идет о ТЗ на информационную систему - от интернет-магазина до ERP). Соответственно, в ТЗ обязан быть прописан процесс, который автоматизируется. Иного просто не дано: не понимая процесса, невозможно описать систему.

Второй аспект: ТЗ должно описывать результат "на выходе". И из этого следует еще один очень важный вывод: в ТЗ должны присутствовать варианты использования системы. То есть, должно быть описано, кто (какая роль) выполняет какой надор действий в системе. Да, и это должно коррелироваться с процессами, которые система автоматизирует.

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

Дальше имеет смысл расписать требования к формам и дизайну. Требования к формам, в идеале - это выделение критически важной информации длдя процесса, с анализом - когда, кто и в каком объеме поставляет нужную информацию. Требования к дизайну тут получаются вроде бы как не очень логичны... но логичны, потому что важно не только то, что будет нести форма в себе - но и то, как она будет выглядеть. Хотя требования к дизайну можно вообще поставить в конец ТЗ, или сделать ссылку на brandbook - тут вариантов масса.

Следующее, что нужно для разработки ИС - определить этапность. Что делаем и что запускаем в первую очередь, что - во вторую и т.д. Это очень важно - так как позволяет четко очертить пожелания Заказчика к тому, что должно работать в первую очередь, а что должно быть запущено в последнюю очередь. Кстати, если есть сроки - то им место тут же.

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

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

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

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

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

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

Получилось довольно много? Да, а кто говорил, что будет просто? На данный момент я написал, наверное, более сотни разных ТЗ - и по итогам работы над этими докумнетами пришел к выводу о том, что если писать документ не ради документа, а ради работы - то он по любому получится большим. Не потому что я так хочу, а потому, что по-другому просто не получится. Тут или качество, или расходящийся процесс.

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.

Про то, что вовремя остановиться - настоящее исскуство

Просмотров: 2758Комментарии: 2
Работа

Всве началось с того, что мне на глаза попался пост "А вы умеете останавливаться?" ( http://yakov-sirotkin.livejournal.com/188897.html) Якова Сироткина. Далее - я всппомнил, что в "интерентах" был пост на ту же темуу, Миши Елашкина - "Как правильно заканчивать мертвые проекты".

Далее - решил поделиться своим видением этой проблемы :))

- к сожалению, факт того, что проект "мертвый" доходит до заказчика проекта в последнюю очередь в 99% случаев

- иногда (но далеко не всегда) проектная команда (или ее отдельные представители) видит, что проект "мертвый"

- и мертвый проект можно сдать (будут ли использованы после его результаты - вопрос отдельный)

- проект может быть "мертвым" вообще на этапе его инициализации

- проект может перейти из "мертвого" в "живой" - но для этого нужна воля заказчика (в первую очередь), очень желательно - воля первых лиц заказчика

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

Принятие решений при выборе ПО.

В тему недавним рассуждениям коллег (Тенцера и Марианны).

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

На самом деле, решения могут быть приняты двумя путями:

  • самостоятельно
  • при помощи внешних консультантов

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

Попытаемся рассмотреть его более пристально. На решение о выборе того или иного ПО могут повлиять причины следующего характера:

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

Вопрос - учитываются ли рекомендации рядовых специалистов при выборе того или иного ПО? Варианты ответа:

  • иногда да (действительно, иногда прислушиваются к специалистам. Весь вопрос в том, что они должны быть действительно СПЕЦИАЛИСТАМИ, а не подмастерьями)
  • а оно надо? (как вариант. Часто жизнь складывается так, что мнения рядовых специалистов топов не интересует - сказано поставить и внедрить, извольте исполнять!)
  • специалисты должны дать базис для принятия решения (это лично мне ближе; так как учитывается и опыт "снизу", и требования "сверху")

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

Еще один интересный момент. Предположим, есть 10 (а лучше, как в анекдоте - 20) систем, автоматизирующих область Х. Нужно выбрать одну. Что делаем? Классика жанра состоит в том, что строим классическое (простите за тавтологию) сито:

  1. Формируем требования (а куда же без них, в конце концов надо представлять, что хочет бизнес-заказчик)
  2. Формируем критерии отбора
  3. Отбираем пару-тройку лидеров (самый интересный момент, о нем как раз я подробно написал выше)
  4. Разворачиваем их
  5. Тестируем (имитируем работу пользователей, возможно - с некоторыми допущениями)
  6. Делаем орг.выводы
  7. Принимаем решение (тоже см.выше).
  8. Подписываем договор, и на внедрение (совсем отдельная песня).

Как оно бывает на самом деле - не мне вам рассказывать:) Вопрос - часто ли срабатывает подобная классика? К сожалению, практически никогда. Почему? Да потому, что:

  • цели внедрения запросто могут быть не определены;
  • требования к продукту существуют в 3..4 головах, причем - разные;
  • критерии отбора сформировать невозможно, т.к. непонятно, что выбираем;
  • понимания, какие системы можно рекомендовать - нет, так как все равно выберут за нас;

Тогда последний вопрос: как жить дальше? Да так: исправлять ситуацию, где возможно, где можно - помогать выбору, где нельзя - подстраиваться и выжимать максимум бизнес-перспектив из поставляемого ПО. В общем, жить полной жизнью и не скучать:)

Кросспост из моего ИТшного блога на ITBlogs.ru

Тенденции к аутсорсингу

В последнее время все больше проектов делается силами аутсорсинговых команд. При этом прослеживается совершенно четкая зависимость: от большого и малого к среднему и малому (привожу свои наблюдения, верные для Петербурга и Москвы; соотвественно, для других регионов/стран расклад вполне может быть иной). То есть, несколько лет назад аутсорсинг был уделом либо очень больших, либо очень маленьких (узкоспециализированных) проектов. В настоящее время аутсорсинг как класс в том или ином виде успешно используется практически везде. (Имеется в виду при реализации проектов любого масштаба).

С маленькими узкоспециализированными проектами все более или менее понятно: существуют целые индустрии по производству сайтов, типовым и не очень решениям на базе 1С и т.д. С большими ситуация тоже более или менее ясна: делать проект, например, по вещанию IP TV оператору связи, который не имел до этого подобного опыта быстрее, надежнее и (скорее всего) дешевле силами аутсорсинговых специалистов/компаний (отдельный больной вопрос аутсорсинга - качество оставим "вне области рассмотрения"). Но жизнь не стоит на месте, и аутсорсинг постепенно пришел в сферу средних и малых проектов. Когда-то давно я сформулировал для себя причины, в силу которых принимается решение об аутсорсинге:

  • Аутсорсинговое решение "на круг" получется дешевле и(или) быстрее, чем самостоятельная реализация;
  • Аутсорсер может предоставить на проект ресурсы, компетенции которых существенно снизят проектные риски;
  • На аутсорсинг отдается не критичное решение, на которое не хочется напрягаться самостоятельно;
  • На аутсорсинг отдается разовое решение, которое должно быть сделано "один раз", и далее про него предпочтительно забыть (самый экзотический вид аутсорсинга);
  • Аутсорсинг является стилем жизни компании-заказчика. Крайний, почти клинический случай;

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

Кросспост из моего ИТшного блога на ITBlogs.ru