Тут же на Хабре поднялась волна обсуждений, где среди прочего звучат заявления о возрождении совка, “не мешайте нам делать свою работу… ну и прочие отрицательные мнения. Мне же документ видится очень нужным и полезным.

Зачем вообще нужны стандраты? Чтобы по-меньше думать при принятии каких-то решений. При этом за счет накопленных и собранных в стандарт знаний повысить качество этих решений. Приведу пример. В 80х годах военное ведомство США озадачилось процедурой выбора вендоров на разработку и поставку ПО. Как выбирать подрядчиков? Надо было ввести какие-то показатели-уровни компаний, чтобы отделить тех, кто работает надежно, от тех кто работает как попало. В иделе этот показатель всего одно число: 1,2,3,4,5… Компания уровня 5ть лучше, чем компания уровня 3, поэтому работаем с компанией уровня 5ть. Так появился  стандарт CMMI (Capability Maturity Model Integration). У компании EPAM – 4й уровень (из 5ти), значит на рынке она выглядит привлекательнее тех у кого 2й или 3й.

Как-то мне приходилось сталкиваться с разработкой интернет-проектов для государственных органов. Занятие это не простое и сопряжено с массой рисков. Результат часто зависел только от качества налаженных отношений с конкретным чиновником. Но если его меняли – можно было выкидывать написанный продукт в мусор – его заместитель требовал совсем иного. Единственный выход – четкая фиксация требований и каждого движения в проекте. Уже тогда я писал ТЗ по ГОСТам, что приводило в восторг чиновников.

Так зачем же нужен такой стандарт?

Планка качества

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

Документ апплеирует к стандартам W3C, что должно сильно радовать веб-стандартистов, а также к ряду положений юзабилити-стандартов.

Формулировка требований

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

Приемка работ

Не секрет, что приемка работ при работе на государственных заказчиков – это всегда проблема. Причин тут две:

Дело в том, что если четко не прописать в ТЗ нефункциональные требования, то заказчик может аппелировать к стандартам отрасли. Если бы мы жили в ЕС, то аппеляция была бы к стандартам ISO. И тут бы мало не показалось.

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

Мне смешно слышать, что с вводом подобного стандарта веб-разработчикам придется туго. Во-первых, можно заделать целый лейбл, что мы дескать делаем по стандарту – айда к нам! Во-вторых, отстроить под этом дело стройный процесс разработки – со стандартом-то оно проще. 

При этом я не хочу сказать, что документ прекрасный, отличный и его надо принимать в неизменном виде. Я не читал весь документ, только то, что выложил Сергей. Из того, что прочитал – масса вещей очень по делу. Имеет право на жизнь.

Что плохо:

Нечеткая структура. Например, про безопасность в разделе Дизайн.  

Стандарты отрасли — это хорошо.

Стандарты не имеют никакого отношения к политическому строю. В СССР была прекрасная методологическая школа на производствах. С результатами этих производств были вопросы, но процессы там были ого-го. Самая бюрократизированная страна на планете – США. Там на все есть стандарт. В Италии существуют, возможно, самые жесткие стандраты винодельческой отрасли (вот где казалось бы творчество!). Кроме как по ГОСТу вина никакого делать нельзя.

Спорный и крайне необычный тезис всей презентации: Человечество должно играть 21 миллиард часов в неделю в онлайн-игры, чтобы выжить. Первая реакция на такой тезис: “Бред!” Заниматься ерундой, чтобы решать проблемы? Тут явное противоречие.

Но вот чем интересна презентация: спорный, крайне не однозначный тезис, выдвигаемый Джейн Макгонигал в итоге превращается в совсем иной. На самом деле она говорит про коллективное решение проблем через игровую среду. Это моделирование ситуаций в виде игр (Мир без нефти). 

Первоначальный тезис был приманкой, основанной на наших стереотипах. Он заставляет следить за изложением материала и внутренне не соглашаться с выступающим. Что есть компьютерные игры для большей части интеллектуальной части общества? Пожиратель времени. Но в конце тезис изменяется! А если эта игра заставляет думать о социальных проблемах? Искать решения или меняет стиль поведения в реальной жизни? Тогда мы скажем, что такие игры полезны. Если выйдешь к публике и сразу скажешь: давайте делать игры, которые будут развивать общество – заработаешь обвинение в занудстве.

В конце мне тоже хотелось встать и апплодировать. Пусть идея наивна, но не лишена благородства, полета.

Disqus позволяет комментировать записи на блоге используя аккаунты Facebook или Twitter. Т.е. не требуется регистрация, не требуется всяких капчей. Требуется лишь пользоваться одним из популярных социальных сообществ.

Если знаете подобные сервисы – поделитесь.

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

Ясны некоторые факты:

• Бесплатных хостингов не будет. Бесплатные домашние странички, блоги тутбая, проекты типа deal.by, где можно было за бесплатно что-то разместить – теперь головная боль. Регистрация каждого из этих сайтов теперь стоит денег, не смотря на то, что они бесплатные.
• Из отрасли при регистрации изымут несколько сотен тысяч долларов чистыми деньгами и еще в разы больше уйдет на накладные расходы за изменение процессов работы компаний. Это работы программистов, юристов,  руководителей, которые должны внедрить новые процессы, написать новый софт, провести ручную регистрацию…
• При этом инвестиции в этот бизнес довольно туманны (я не в отрасли, но что-то мне подсказывает). С одной стороны нужны новые дата центры, с другой стороны играть по правилам, которые все время меняются мало энтузиастов. Провайдеры уже стонут от политики Белтелекома, которая фактически ведет к их разорению. Монополист есть монополист.
• С бесплатным wi-fi в кафешках Беларуси можно попрощаться. Владельцам кафе будет проще не предоставлять инетрнет своим посетителям нежели вводить карточную систему. С другой стороны это открывает поле для работы сетей типа Yota, да и мобильные операторы будут рады, что набирающего обороты конкурента удалось затоптать новорожденным.
• При всем при этом не понятно главное: как будет осуществляться контроль. В любом контроле есть несколько составляющих. 1. Стоимость контроля должна быть ниже, чем стоимость контролируемой информации. 2. Стоимость контроля возрастает  при плохой структуре информации, т.е. ее низком качестве. 3. При этом конролировать надо не только подачу/не подачу сведений, но, более того, качество и полноту.
  Очевидно, что стоимость контроля этой информации высока. Судя по ответам о ресурсах для контроля никто пока и не думал.

В этой связи я помню, как покупал wifi точку для дома несколько лет назад. Мое желание не пользоваться дома проводами обломилось на желании чудной организации БелГИЭ пробраться в каждый дом и контролировать там все устройства. Ни одна компания не продала мне WiFi хаб, отправляя в БелГИЭ за разрешением на его покупку. Уже звучит как анекдот. Я позвонил и уточнил у специалистов в БелГИЭ как это можно сделать. Четвертый человек, с которым меня соединили, знал ответ. Надо было совсем не много:

• Написать обоснование необходимости высокочастотного приемо-передатчика у меня дома.
• Составить план его размещения на плане квартиры.
• Утвердить этот план (Правда, я не понял где, наверное, в домоуправлении. Вот бы они удивились!).
• Сдать все документы в БелГИЭ (там был еще какой-то перечень).
• В течение месяца комиссия должна была выдать заключение о возможности установки в моей квартире высокочастотного приемо-передатчика для использования в личных целях. Выдадут справку.
• После чего можно идти и покупать этот передатчик в магазине. Элементарно просто.

А когда я спросил у того же отвественного сотрудника, что будет если я не буду ничего этого делать, а просто проездом в Киеве куплю этот передатчик и поставлю дома? Кто об этом узнает, кто найдет и кто накажет? Оказалось, что никто. Оказалось, что контроль вообще не в их поле деятельности, что они этим не занимаются. А кто и как занимается – никто не знает.

Через месяца 3 эту процедуру отменили за абсурностью. Сделаю скромное предположение, что количество зарегистрированных устройств для частного использования стремилось… к нулю.

Так вот что интересно. По словам БелГИЭ на текущий момент количество зарегистрированных интернет сайтов также – ноль (интересно, почему не зарегистрирован сам сайт БелГИЭ, Белтелеком и пр., а?). Что будет если 1го июля в стране будут зарегистрированы лишь несколько десятков проектов и несколько десятков email-адресов? Отключать страну от интернета?

Я вот что хочу подчеркнуть: Все эти люди говорят о РАЗВИТИИ национального сегмента сети интернет. Ни больше, ни меньше. Вот цитата:

…создания условий для дальнейшего развития национального сегмента глобальной компьютерной сети Интернет…

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

Как мы выберем конкретную систему лифтов для конкретного здания? Если поймем как будет использоваться здание, понимаем систему работы людей внутри — подберем под них систему обслуживающих лифтов, лестниц, эскалаторов. Это кажется очевидным.

Хорошо, а теперь представим, что в нашей команде есть человек, который всегда работал только с жилыми зданиями. Назовем его Грег. Грег свято верит в систему “1-n, n-1″ — она идеальна, проста и понятна всем. Каждый кто говорит, что это не так — ничего не понимает в жизни и лифтах. Все остальные системы — сложные пережитки прошлого. Грег — евангелист простой системы управления лифтами.

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

Но еще круче, если мы не изучим ни одной системы управления лифтами (или командами). А выдадим менеджеру короткий емкий тренинг мастерски умещенный в двух словах: Good Luck! Ведь что для менеджера главное? Заряд оптимизма! Петарда в ж…! Зачем ему знать системы управления проектами, модели построения команд, методы рассчета и учета рисков, схемы планирования, методы мониторинга и контроля, GTD?

Важно только не терять вместе с ним надежды, что он всему этому научится сам! За ваши деньги.

Во второй день читал мастер-класс про управление рисками в проектах. Забавное дело, в воскресенье встал рано утром, бытро собрался и чуть было не приехал на мероприятие на час раньше. Вспомнил об этом уже на пол пути в машине, остановился и набросал в лэптопе небольшой mind map по рискам, которые могут произойти со стартапом. План был такой: презентации нет, поэтому разберу вместе со слушателями риски, которые могут произойти с их новым проектом. Приехал, пообщался с участниками… и понял, что если рассказать им все риски, которые с ними могут произойти — порбосают любые начала.  Пришлось подготовить презентацию за 20 минут (как настоящий джедай), благо материал уже был.

Зачитал основы риск менеджмента, а составленный mind map пообещал выложить тут, на сайте.

Держу обещание, поэтому файл тоже можно забрать от сюда: startup_risks.mmap.

Коротко о моих впечатлениях.
Вместе со мной мастер-класс проводила Елена Нупрейчик из программы MBA при БГУ. По большому счету мы говорили с ней примерно про одно и тоже, но несколько разными словами и примерами. Повторение, как известно, мать учения.

На встречу пришло довольно много человек. По моим оценкам от 40 до 50, я думал, что будет меньше, поэтому было приятно увидеть заполненную аудиторию. При этом когда мы спросили кто будет участвовать и презентовать проекты оказалось всего около 5ти участников.

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

Является ли наличие керамического чайника непременным признаком говноменеджера? (6 вопросов).

Нет, это совершенно необязательно (например, если у птицы есть клюв – она же не обязательно дятел?). Для того, чтобы уверенно классифицировать объект как говноменеджера, требует систематическое следование им 2-3 или более изложенным в посте заповедям. А фарфоровые чайники – это внешнее, просто повод приглядеться к своему менеджеру получше.

Сегодня даже при мне 3 раза спросили про керамические чайники.

Похоже, что заметка Дениса ушла в народ. Да. 
Думаю, что на dev.by эта заметка произвела бы эффект разорвавшейся бомбы.

Лавра

Мое посещение конференции началось с неожиданной прогулки по Киевско-Печерской Лавре. Хорошая утренняя прогулка по памятнику зодчества охраняемого Юнеско. Да, это прекрасно.

«Лавра» на Яндекс.Фотках

Разве, что мороз ниже 20 градусов мешал наслаждаться архитектурой золотых куполов.

Agile Base Camp

«Твиттер-фид на конференции» на Яндекс.Фотках

К большому сожалению на конференцию не смог прибыть мой коллега Денис Петелин с докладом про выбор инструментов для Agile проекта. Оказалось, что данная тема крайне возбуждает умы проджект-менеджеров и разработчиков ближнего зарубежья. Вместо выбора тул-сета  я зачитал аудитории семинар о том, как управлять рисками в проекте. Это мой внутрениий тренинг в EPAM.

На мой взгляд риск-менеджмент относится к общей практике управления проектами и прекрасно ложится на agile-проекты. Безусловно там есть свои ньюансы. Риски waterfall проектов — это одна из приичин самого появления agile как методологии.

Этот семинар вызвал массу интереса со стороны… епамовских менеджеров. Уже поступили запросы на проведение внутренних вебинаров для agile-команд.

Coach Camp

«Coach Camp» на Яндекс.Фотках
Второй день. У меня сложилось такое ощущение, что не все из тех кто были на этом собрании являются (или планируют являться) agile-сенсеями. К сожалению, опоздал на знакомство. Но тем не менее в ходе наших обсуждений и разговоров я записал для себя много интересных моментов, которые надо прорабатывать вглубь.

Выяснять “что же такое Agile” не в моем вкусе. Подобные методологические споры лучше оставить профессионалам в методологиях. Нам же практикам лучше состредоточиться на том, как эти идеи двигать в массы. В частности, в наших компаниях и среди наших клиентов.

Для меня agile состоит из следующих составляющих:

• Философия.
  Как, зачем, почему в agile придумали работать именно так.
• Процессы.
  Конкретные процессы, которые надо ставить в компании + инстументы, позволяющие работать по agile.
• Знания + навыки.
  Набор знаний, которые надо донести до команды, которая думает использовать agile, а также навыки, которые надо помочь им развить.

По этим трем направлениям мне видится внедрение agile в компании от 30 человек. В более маленьких компаниях процессы никто не описывает, а выбор иструментов уже сейчас довольно широк (BaseCamp, AcuNote, JIRA…, не говоря уже про task-board и Excel).

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

Задумайтесь об этом, когда будете внедрять agile.

Например вы написали программу, протестировали приложение, прочитали семинар или  приготовили макароны. Как вы определите, что достигли желаемого результата?

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

Если не вдаваться в сложные рассуждения на тему абстракций, то у нас мало  первоначальных метрик для оценки подобных заданий. Главное о чем мы можем  спросить себя: “Доволен ли тот, ради кого мы старались?”. Если этот кто-то ваш  начальник — вам продложают платить зарплату, если партнер, то продолжается работа по  контракту и проект развивается.

Следующий шаг — ответить на вопрос: “Что делает его довольным?” Ответы могут быть  такими:

• 80% фич по проекту поставляется во время.
• Рентабельность проекта держится на уровне 20%.
• Знания в компании накапливаются.
• Текучесть кадров снижается на X%.
• И т.п.

Часть из этих подцелей будет измерима довольно просто, для части надо придумать метод измерения. Каждая цель и подцель разбиваются на задачи, определяющие достижение цели. В качестве пояснения я изобразил такую картинку:

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

Вот здесь мы можем сформулировать еще одно важное утверждение. Формулирование целей решает две задачи:

1. Задает базис для принятия решений и формулировании задач.
2. Позволяет валидировать и верифициаровать результат. Т.е. по сути принять еще одно решение — цель достигнута.

Если говорить о процессе разработки проектов, то целями в этом случае являются фичи, которые разрабатываются и поставляются клиенту. В этом случае:

• Цель – фича, набор фич, итерация.
• Задача – задачи по разрботке, документированию, внедрению, поставке ПО.
• Валидация/верификация задачи — тестирование, тестовые сценарии и т.п.
• Валидация/верификация цели — Definition of DONE.

Цель — это и метрика и отправная точка.