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

Зачем вообще нужны стандраты? Чтобы по-меньше думать при принятии каких-то решений. При этом за счет накопленных и собранных в стандарт знаний повысить качество этих решений. Приведу пример. В 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 минуты… Практика показала, что уложиться можно.

Завтра, в пятницу 9го апреля выступаю с небольшим мастер-классом по “Исскуству презентаций”. В рамках подготовки проекта Minsk StartUp Weekend. Надеемся, что два мастер-класса и неделя подготовки помогут участникам достойно подготовиться к данному мероприятию.

Некоторые темы выступления согласовываются, но в кратце:

• 6ть вопросов, на которые ждут ответа инвесторы.
• Подготовка презентации. Плохой-хороший слайд.
• Тренировка или почему ленивые платят много.
• Презентуем: любая импровизация должна быть отрепетирована или как побороть свои нервы.

Об условиях участия в мастер-классах написано как на официальном сайте мероприятия, так и на нашем сайте Agile.by.

До встречи!

Сама по себе самоорганизованность вещь безусловно полезная и крайне важная. Но вот в чем вопрос: на одинаковых ли принципах строится самоорганизованность менеджера и сотрудника?

И вот тут есть маааленький ньюанс. О котором можно было бы не упоминать… Подчиненные != менджеры. Кто они? Очень часто это программисты и тестировщики. Язык не поворачивается назвать их рабочими, поэтому для простоты назовем их Worker’ами.

Посмотреть на Яндекс.Фотках

Какая разница между этими двумя типами?

У них разный ритм работы (а часто и жизни).

Рабочий день Manager’a наполнен встречами, звонками, поездками, ответами на важные письма, коммуникациями в разных видах. Вот как выглядит календарь типичного менеджера:

Посмотреть на Яндекс.Фотках

День менеджера делится на четкие кусочки времени по 30-60 минут, о которых он говорит так: “Привет, Паша, у меня в среду после обеда будет дырка в расписании, можем заделать колл в это время.” Все задачи менеджеры делят по типам “что” и “когда”, настраивают себе ремайндеры, покупают телефоны с поддержкой календаря и списка задач, синхронизируют его со своим Outlook’ом.

Рабочая неделя Worker’а выглядит несколько иначе… Примерно вот так:

Посмотреть на Яндекс.Фотках

Весь рабочий день worker’a можно разделить на 2 части:

• ДО обеда.
• ПОСЛЕ обеда.

Все. Нет никаких окошек, нет никаких коротких отрезков. Ритм разработчика — сидеть и делать задачу, думать, в башке крутить, искать информацию, советоваться с коллегами. До тех пор пока не поборет. Смена контекста для worker’a происходит медленно, а входить в новый контекст надо с усилием. Менеджерами как раз и становятся те, кто способен много коммуницировать и быстро менять контекст.

Фундаментальное непонимание разницы рабочего ритма между разработчиками и менеджерами приводит к конфликтам.
Менеджеры получают свою долю раздражения, разработчики — снижение мотивации.

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

Выводы тут простые:

• Чем меньше отвлечений, тем лучше разработчик входит в “поток”.
• Планировать совещания и мероприятия лучше ближе к обеденному перерыву или концу рабочего дня. Можно начинать день со стендап-митинга.
• Если митинг на 2 часа запланирован где-то “после обеда”, часть дня “ПОСЛЕ обеда” для разработчика будет потеряна.
• Учить личной эффективности worker’ов надо в ключе ритма их работы. Time management для менеджеров и разработчиков отличается.

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

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

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

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