Бескультурье

Ох, как давно не писал в блог... Ну да ладно, всему своё время. Я ж тут не периодическое издание изображаю )

Сегодня хочу поговорить о культуре разработки ПО. Перефразируя БСЭ, можно сказать, что культура разработки ПО - это определённый уровень развития команды или отдельного человека, выраженный в типах и формах организации деятельности этой команды или этого человека, направленной на удовлетворение нужд потребителя разрабатываемого продукта или услуги. Культура разработки ПО, таким образом, может быть у отдельного человека, у некоторой проектной команды, у IT-отдела или у целой организации, если она специализируется на разработке ПО.

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

Проиллюстрировать это можно простым бытовым примером. Когда-то, лет восемь назад, задумали мы построить загородный дом. Участок у нас уже был, но в месте, где можно было поставить дом, была низина. Пришлось поднимать уровень грунта почти на метр, чтобы талые и дождевые воды уходили от дома, и под полом было сухо.

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

- У нас насыпной грунт на участке. Какой фундамент вы предложили бы заложить для загородного дома?
- Есть лента 50 см высоты, есть метр, есть метр двадцать...
- Но какой вариант подходит к нашим условиям?
- Какой вы скажете, такой сделаем.
- Но я не профессионал в закладке фундамента. Как я могу вам сказать, что мне нужно?
- Ну, вы подумайте, и скажите...

Аналогично обсуждалась толщина стен, их материал, вид кровли и все остальные существенные (!) вопросы строительства. В итоге мы уходили, понимая, что толку не будет.

Закончилась история тем, что на соседней улице в нашем посёлке мы познакомились с семьёй, у которой была своя небольшая и никому неизвестная строительная фирмочка. Но на наш вопрос они ответили честно и профессионально:

- Мы не можем сказать сейчас, нам надо прошурфить грунт.

Смотрите: мы посетили самые известные на тот момент фирмы, и никто даже не задался вопросом, как сделать правильно. От нас хотели решения, которое сняло бы любую ответственность с застройщика, но позволило бы ему как можно больше заработать. И только в этой маленькой фирме работали настоящие строители, которые взяли профессиональную ответственность на себя. Именно это я называю культурой: эти люди не просто знали, как можно построить дом. Они знали, как это сделать правильно в конкретной ситуации, понимали и принимали свою ответственность за их профессиональные решения.



Сейчас у меня чувство дежавю. Нет, я не строю дом. Я главный IT-архитектор в Роспатенте. Но я снова имею дело с самыми известными компаниями, которые вроде бы должны иметь развитую культуры разработки ПО. И снова я слышу тот же ответ: как вы скажете, так мы и сделаем. У вас в техническом задании так написано, мы так и делаем.

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

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

Наша IT-индустрия поражена этим вирусом безответственности, жажды быстрой и безнаказанной выгоды, непрофессионализма и откровенного безразличия к нуждам заказчика. Это настоящая эпидемия, поразившая уже 9 проектных команд из каждого десятка. Это самое настоящее отсутствие какой-либо культуры разработки. Знания есть, навыки есть, но нет культуры.

Безусловно, это не снимает ответственности с заказчика системы. Но он не обязан проявлять профессионализм в деле разработки ПО. Он не может и не должен формулировать требования или ставить задачи на языке, принятом среди профессиональных разработчиков информационных систем. Заказчик может только описать свои потребности на языке своей предметной области, и увы, не более того. Если от заказчика требовать профессиональных знаний в области IT, то нафиг вы, разработчики, ему сдались: он сам сделает всё, что ему нужно, быстрее, чем вам, недотёпам, донесёт свои потребности, которые на самом деле вы просто не хотите слышать.

Показатели качества по ISO 9126

На тему показателей качества я писал полтора года назад в статье "Анализ действующей системы: характеристики качества". Статья была основана как раз на модели, предлагаемой стандартом ISO 9126.

Сегодня в моём проекте в Инстаграме я опубликовал презентацию "Характеристики качества ISO 9126". Вот ссылка на саму презентацию.

Характеристики качества. FURPS+

Новая презентация на моём Инстаграмм-канале рассказывает о классификации FURPS+. Часто эту классификацию рассматривают как классификацию требований к программному обеспечению, хотя она имеет и более широкое применение.

Ссылка на презентацию.

Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 5

Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей.

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

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

Collapse )

Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 4

Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей.

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

Сегодня публикую четвёртую часть. В ней авторы подводят некоторый итог их работы.

Collapse )

Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 3

Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей.

Первая часть была посвящена применяемой методике классификации и общей структуре отчёта. Во второй части отчёта речь шла о категориях бизнес-целей.

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

Collapse )

Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 2

Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей.

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

Collapse )

Постановка целей с использованием модели SMART

Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 1

Как-то выпал из моего блога перевод отчёта о классификации бизнес-целей, сделанный мной ещё год назад. Пожалуй, надо восполнить этот пробел.

Ввиду ограничений на объём статьи в LJ сегодня публикую только вводную часть.

Collapse )

Интервью для "Школы системных аналитиков"



Спасибо Ане Гасраталиевой за приятное общение и её неравнодушное отношение к своей работе. Это очень редкое качество, которое я очень ценю в своих коллегах.

А почитать интервью можно на сайте "Школы": "Интервью с архитектором"

P.S. Вот таким балбесом я был 20 лет назад )