SoftwarePeople 2011 - Макс Цепков

Конференция SoftwarePeople 2011 7-8.04.2011. Попытка сделать отчет в реальном времени.

Общие впечатления

Общее впечатление — конференция удалась. Она наиболее профессионально организована из всех тех, на которых я был за год. AgileDays-2011 и ADD-2010 мне показались более живые в части общения участников, но профессионализма им не хватает. Правда, они моложе и более дешевые, а профессионализм — он не бесплатен.

Плюсы конференции — online трансляция экрана и выступлений по инету. Синхронный перевод английских докладов, причем высокого качества. По отзывам, это многим важно. А мне — помогает писать этот пост во время не слишком интересного английского доклада — русский я слушаю в фоне, не боясь пропустить важное, а английский — не могу. Еще хорошо — программа вложена в бейдж в свернутом виде, это очень удобно. Есть WiFi и удлинители для ноутов, правда не слишком много, но дефицита видно не было.

На конференции попробовали практику пленарных докладов, принятую на зарубежных конференциях… Она очень хороша, когда доклад — достоен. Как у Книберга на Agile Days. Реально достойный пленарный доклад — это очень сложно, потому что он должен быть комбинацией общего смысла, ценного для новых слушателей, но содержать интересные моменты, которые оценят специалисты, свободно владеющие основами. Здесь реально достойный доклад был у Мейдена, но сильно не все на таком уровне абстракции мыслят и восприняли идеи. А вот у Ютты — наоборот, популяризация, ликбез, и там нет новых мыслей и идей, которые бы были интересны специалистам. Более того, с моей точки зрения, у нее вообще не было конкретики, и шли очевидные вещи. Но в перерыве некоторые участники говорили мне, что услышав в докладе в очередной раз известную ранее вещь, они поставили себе пометку — попробовать, сказано было своевременно и подтолкнуло. Доклад Коскелы — посередине между ними. А с докладом Кристенсена по HTML5 получилось совсем неудачно — он воспринимался как технический, и, в общем, таким был, и как таковой — был не интересен приличной части участников. А альтернативы не было.

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

Отдельные мысли

• Программисты, ваш собственный feedback на MS или Яндекс — вы просто их меньше ненавидите :) Кто хоть раз написал благодарность за новый функционал? Будьте готовы к тому же от пользователей…
• Как известно, сон разума рождает чудовищ. А коллективный разум бюрократии спит беспробудно. Ergo, стандарты — чудовищны.

Что понравилось — доклады на 5

Нил Мейден (City University London) Requirements Engineering as Creative Problem Solving: New Opportunities to Improve your Practices

Хороший понятный английский, но очень быстрый, переводчик не слишком успевал. Но перевод — хороший!

Очень хороший доклад. Креативная тема, и в целом с примерами и техниками. Реально достойный пленарный доклад — это очень сложно, потому что он должен быть комбинацией общего смысла, ценного для новых слушателей, но содержать интересные моменты, которые оценят специалисты, свободно владеющие основами. В данном случае перекос был в сторону подготовленных слушателей — те, кто не имел дело со сложными проектами или не мыслит на таком уровне абстракции, сочли доклад водой. Для других — были новые мысли и подходы в части именно креативных решений, там много ценного. А для меня ценным было именно их сочетание с реальными примерами, причем не из общеизвестных, типа креатива от Apple, а из реальных бизнес-областей — авиаперевозок.

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

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

В целом — хорошо, посмотрим что будет на тренинге.

Юрий Шиляев (EPAM Systems) Программа обучения на 50 000 человеко-часов или как отстроить образовательную программу в ИТ-компании

Доклад о практиках обучения в EPAM. По верхам — ограничение времени, но с конкретикой, и это — хорошо. EPAM организовал обучение потому как берет студентов, других кадров в нужном объеме — нет. В том году — 600 человек новых. В Белоруссии пытаются поставить образование в ВУЗах, дать заказ — ВУЗы говорят нет преподавателей. Поэтому приходится самим.

Формы.

• Open тренинг — придти может кто угодно по регистрации. Например, по SCRUM
• Workshop — когда надо обучить команду, может тому же scrum.
• Менторинг-программы. Об этом было подробнее.

Менторинг. Есть ментор-куратор. Он составляют карту экспертизы, что должны уметь люди про профилю. Группа — ментор и менти — кто учатся. Супервайзер — периодически смотрит за обучением в группах, что оно не превратилось в формальность. Для для менторов и лекторов проводят тренинги, эта отдельная программа подготовки. Самое сложное — вырвать менторов из продуктивити. Они же реально заняты в проектах, они опытные. Но они нашли способом, каким образом ментор и менти остаются в продуктивити. Лучше, когда ментор и менти из одного проекта, бывает не так, но тогда больше риски, особое внимание. Задачи обучения бывают как учебные, так и из проектов менти. Но при этом нужен постоянный прессинг куратора — продолжайте обучение, иначе сваливаются в производство.

Программа — реально длинная, 8-9 месяцев, этим отличается от тренинга на 1-2 дня. Для менти в программе минимум 8 часов, плюс 6 — выполнение заданий. И все в личное время, за это время не платят зарплату! Как университет. Никто в эту программу никого не тянет. Ресурсный менеджер и руководитель проекта — иногда одно лицо, иногда разные. Решение про обучение сотрудника принимает ресурс-менеджер. Обязательно отслеживают обратную связь и от менеджеров сотрудника по результатам обучения.

Как делать.

• Найдите людей. Люди, которые хотят — есть.
• Сделайте тренинг для тренеров
• Найдите ответ — зачем тренеру этим заниматься
• Принципы
  • Все читают тренинги, и менеджеры тоже
  • Шире охват, вебинары с записью
  • Думайте как сделать больше. Каменный век кончился не потому, что кончились камни.

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

Ольга Павлова (UsabilityLab) Менеджеры и программисты: как перестать обижаться друг на друга?

Доклад — об обидах, обобщение опыта разных компаний и ситуаций. С ее точки зрения, это — актуальная проблема в отношениях менеджер-программист, о которой достаточно мало говорят и думают, несмотря на литературу по этому поводу. Я думаю, во многом это вопрос культуры в целом — про обиды в семье тоже как-то не слишком учатся несмотря на имеющуюся литературу, а это вещи одного порядка.

Доклад рассматривал ситуацию между обобщенным менеджерам и обобщенным программистам. Было достаточно много различных ситуаций и вариантов поведения, которые мне во многом знакомы по литературе. Однако тем, кого тема интересует доклад посмотреть полезно. Или если сомневаетесь, а времени жалко — можно пролистать слайды, и если там есть не очевидные вещи — то смотреть доклад.

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

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

Из интересных мыслей.

• Обида — это общественное явление: дети до 2 лет не умеют обижаться, а потом учатся.
• Обида — когда есть какое-то общее дело. Выводит из того, что у людей разные представления что хорошо для общего дела. Тут я не согласен, корни обиды в разных оценках поступка, цели чаще разделяются, просто человек не подозревал про полученную интерпретацию.
• Программисты — ошибки предметны. Ошибки менеджеров — они сложно проявляются, как следствие — ненаказуемы. И потому идут обиды — виноваты всегда программисты.
• Гладить по головке — работа менеджера. Не забывайте. Остальное специалисты сделают сами. Но гладить надо искренне. А еще — высказывать уважение сотруднику, тоже искренне.
• Про ответственность. Ее должен брать тот. кого беспокоит ситуация с возможными обидами. Коллективный разум — безответственный, ему свойственно думать, что высказанные идеи таинственным образом осуществятся, и многое другое. А потом возникают обиды.
• Обиды обидами, но паранойю — не лечим.
• Вопрос: менеджер — начальник или лидер. Ответ — это не то и не другое. Без начальников, которых гоняют — можно обойтись. Но лидером быть не обязательно, не все склонны. Главное дать результат.

Приличные доклады — на 4

Тимофей Басанов (QIWI) Управление своим временем, используя пост-GTD технологии

Докладчик несколько раз пытался использовать GTD, но он развивался, появлялись приоритеты и сроки, в результате все рушилось. Я: Аллен, собственно, настойчиво предостерегает от этого в книге. А потом — прочитал книгу Today Work Control и эта технология — успешно у него прижилась для повседневных дел. С моей точки зрения — это почти чистый GTD в оперативной части. Дела ведет в outlook, 3 приоритета: 1 — сегодня. Внутри приоритета — по дате дела. Два горизонта: сегодня и «близкие дела» — неделя-две. Мелкие задачи по умолчанию ставить дальше близкого горизонта, на понедельник — и раскидывать. Дела потихоньку протухают, естественным образом опускаясь в списке по дате. Поэтому оперативно дел немного, в понедельник полчаса-час разбираешься с тем, что всплыло. Как-то так. Да, в книге 90 % воды, но краткого изложения он не нашел.

Лассе Коскела (Reaktor) Specification By Example

Доклад Коскелы — приличный, хотя пленарный доклад. Но не замечательный. Про то, что такое Specification By Example. На уровне ликбеза, но с некоторой конкретикой, которая позволит попробовать. С достоинствами метода и типичными ошибками. Но без границ применения. И без сравнения с другими методами — многие достоинства и практики присущи не только Specification By Example, они есть и в других методах, но это явно не сказано. Соответственно, для тех, кто знает широкий спектр методов доклад не слишком полезен, а многие примеры выглядят как баяны.

По сути доклада.

Четыре причины дефектов — programmer, design, req, systemic errors. Specification by example — убрать ошибки требований. Пишите для этого пример. Но в его изложении это из серии идеального заказчика и простой задачи. Потому что алгоритм на примерах не задать. Сложную работу формы — тоже не слишком задашь, если цели за рамками. Но как часть тестирования, проверки понимания — да полезно. Но тогда пишет не заказчик, он — проверяет, и именно это дает гарантию понимания — ИТ по общим описаниям от него сделали кейс и сделали верно. Это понятная конструкция. Только писать должна команда, это получается часть разработки. А он предлагает скинуть на заказчика. Это, в целом, только местами работает. На самом деле, вопрос уровня, деления между acceptance scenario and test case. Методика это дело, похоже, смешивает.

Практика — specification workshop внутри итерации. До конца итерации — distill, и на следующей — разработка. Практика общая вообще для постановок командой (мы применяем), а не только в этой.

Сергей Авдошин (ГУ ВШЭ) Формирование современных образовательных стандартов в области программной инженерии: факторы влияния

Доклад был о формировании образовательных стандартов и я пошел потому, что на параллельный доклад по ASP.NET точно не хотел, особенно услышав того же докладчика на HTML5. Докладчик рассказывал про тенденции международной (не российской!) бюрократии в области образовательных стандартов ИТ. Материалом владел. Я слушал для общего представления, делал заметки, параллельно оформлял отчет.

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

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

Что касается ВШЭ, то она движется по пути повышения качества образования, сотрудничества с иностранными университетами, ищет для этого различные формы. В общем, люди работают на международном уровне и делают что могут. Например, есть совместная программа с университетом Eindhoven (там работал Дейкстра) — два магистерских диплома. Для студента бесплатно и даже со стипендией, хотя себестоимость 17т евро. А сам университет — базовый для Phillips. Практически, думаю, таким образом привлекают наши кадры… А для них (ВШЭ) — это способ доступа к исследованиям мирового уровня, в России таких исследований нет.

Остальное

Ютта Экстейн (Независимый эксперт) Agile by Planning Continuously

Пленарный доклад, интересный преимущественно новичкам. Это чистый ликбез по agile. Планирование и оценка на daily scrum, 2 недельные итерации поставка каждые 3-6 итераций… Мерить скорость и прочее. Причем — совсем БЕЗ конкретики. Популяризация, и там нет новых мыслей и идей, которые бы были интересны специалистам. Даже если у нее самой за этими словами стоит много конкретики и практики, но в докладе она не проявилась совершенно, даже в виде примеров. Общие слова, вода. Для проблем не только не давали решений (понятно, что многое от условий зависит) — даже не формулировали вопросы, которые правильно задать, чтобы придти к ответу.

Так что с моей точки зрения, у нее вообще шли очевидные вещи — на уровне тех умозрительных программистов, погруженных исключительно в разработку. Хотя, может я ошибаюсь, и они не умозрительны, а распространены?

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

Из любопытного — тезис «Планирование — все, планы — ничто» со ссылками на великих.

Мадс Кристенсен (Microsoft) Writing HTML5 applications using ASP.NET

С этим пленарным докладом получилась проблема. Второй доклад в 2-часовом слоте. Технический или воспринимаемый так, поэтому интересный не всем. Думаю, по HTML5 можно сделать концептуальный общезначимый доклад, и я даже на ADD-2010 видел неплохой доклад. Но этот доклад — весьма сумбурный, во многом — поток слабосвязанных мыслей. И сам HTML5 для него — зонтик для списка разнородных технологий.

Был живой пример — собственный сайт, куда каждый день выкладывается новая фотография. Но сайт весьма примитивный и не слишком понятно, что именно иллюстрирует. Потому что там блохи, мелочи. Которые, были бы уместны тем, кто на коленке делает собственный сайт, а не профессионалам. Да и на коленке те, кто заморачивается — гораздо более сложные конструкции делают. Хотя некоторые фонты и повороты — которых не было раньше, причем с учетом конкретных броузеров… Частные штуки никуда не уйдут, хотя что-то в стандарт и провалится.

А еще это местами антиреклама — if и структурные операторы внутри html, обрамленные <% %>… Конечно, разработчики и это съедят — а что им делать. Но на мой взгляд, это наглядная иллюстрация того, что у бюрократии разум спит беспробудно и неизбежно рождает чудовищ. Да еще копирайтеры проявились — стандартизаторы не смогли договорить вендоров на использование единого видео-формата, для каждого броузера надо подкладывать видео файл в своем формате!

По впечатлениям от стандарта у меня объединились две идеи. Как известно, сон разума рождает чудовищ. А коллективный разум бюрократии спит беспробудно. Ergo, стандарты — чудовищны.

Заметки по докладам

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

Нил Мейден (City University London) Requirements Engineering as Creative Problem Solving: New Opportunities to Improve your Practices

Хороший понятный английский, но очень быстрый, переводчик не слишком успевал. Но перевод — хороший!

Очень хороший доклад. Креативная тема, и в целом с примерами и техниками. По отзывам — доклад многие сочли водой. Я: потому что на таком уровне абстракции не мыслят. Меня наоборот навело на многие мыслим и понравилось.

Традиционный взгляд:

• разделить req and design
• не спускаться до решений на выявлении требований
• при этом к требованиям подходить креативно — они проектируют свойства системы

Заказчик customer отражает реальность, он не представляет будущее, это — задача ИТ Я: спорно, на самом деле, хотя с научно-инженерной точки зрения понятно.

На середине проектор перестал показывать слайды, пошел синий экран… Через некоторое время достал бумаги, решил продолжить интерактивно. Тут оно пошло.

Creativity def Sternberg 1999. psihology etc 42 models of creativity

Osborn 1953 CPS (Req Eng for Creat problem solv) vs soft model

• problem undestand — goal/req
• idea generation — in soft diferent: decomposition and вывод решения, не креатив
• planing action

Я: Пошел полет своей мысли… Я: это потому, что ИТ рассматривают как некреативную область, вернее ограниченно-креативную, средства. Как строительство, когда план дома предписан, придуман, и задача — просто из материалов это сделать, доточить где конструктивно плохо получилось.

Причины — во многом в том, что решение комплексное, бизнесовую часть ИТ не знает, в лучшем случае только понимает, а значит решение — только совместное.

При этом в строительстве на всех уровнях есть пространство креативных решений архитектора. Только это сильно дороже. И сложнее — особенно чтобы застраховаться от кошмара эстетствующего диазйнера. ИТ тоже часто предлагают решения, которые сильно впереди возможностей пользователей

Но совместная креативность нужна, примеры вполне рабочие — из авиаперевозок, управление посадками в Хитроу и сегменты в европейском воздушном пространстве. Однако, есть подозрение, что там бизнеса много…

В Хитроу они использовали ЖД опыт — вполне продуктивно, сумев найти отображение.

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

Творческие семинар, визуальное представление use case. Правда, тут вопрос — что он под ними понимает, скорее это фрагменты предметной области. Но их снижают до какого-то скелета решения — визуально…

За 4 дня — 46 страничный отчет…

В сегментах пространства — тоже две аналогии — управление скоростными дорогами и заключение контрактов

Я: Собственно, в этом причина успеха — если участие принимают люди с широким опытом. Они мыслят, знают решения многих областей и могут их применить в новом проекте, дав бизнесам новые идеи, которые за рамками их опыта.

Инструменты — storyboards, визуальная доска, карточки. И это — эффективно, интерактив и много прочего.

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

Эффективный workshop надо хорошо готовить — сценарии, аналогии и прочее. Это — понятно.

Сейчас доски некоторым образом воспроизводятся на web — для распределенного интерактива, когда нужно..

Вопросы…

Команды — 15-20 стейкхолдеров и других экспертов

Тимофей Басанов (QIWI) Управление своим временем, используя пост-GTD технологии

Отзыв на бумажках, написать.

Ютта Экстейн (Независимый эксперт) Agile by Planning Continuously

Все-таки это чистый ликбез по agile. Планирование и оценка на daily scrum, 2 недельные итерации поставка каждые 3-6 итераций… Мерить скорость и прочее. Причем — совсем БЕЗ конкретики. Даже если у нее самой за этими словами стоит много конкретики и практики, но в докладе она не проявилась совершенно, даже в виде примеров. Общие слова, вода. Для проблем не только не давали решений (понятно, что многое от условий зависит) — даже не формулировали овпросы, которые правильно задать, чтобы придти к ответу. Это для тех умозрительных? программистиов, погруженных исключительно в разработку. Или я ошибаюсь, и они не умозрительны, а распространенны?

Правда, пообщавшись в перерыве, я понял, что это я считаю водой очевидными, а ряд участников заметили себе все-таки попробовать те или иные практики, о которых они в очердной раз услышали в докладе. повторение — мать учения :)

Начала с agile is buzzword…

Общие принципы. Идеализм от тоуоты?: если user не используют инструменты или процесс — bad process or tool? not user.

Не делайте слабый (начальный?) функционал сложными средствами. Но потом — добавляете технологию…

Разделение планов и процесса планирования. Процесс — важен, должен быть. Планы — вторично… Ссылки на Эйзенхауэра и Черчиля :) для заказчиков…

Как-то все сильно тривиально и обще… 12:06 может, потом по-другому будет. Работающее ПО — лучший feedback. Я было подумал, что для заказчика, в ответ на его усилия по планированию… Оказалось — для разработчиков, которые по нему могут получить отклик. :) Понятно, что на неработающее Поони отклика не получат. Но на работающее все тоже не просто.

Классический цикл: plan — do — inspect — adopt

Раз планирование — все давайте сделаем его ежедневным… daily scrum.

Итерации, поставка каждые 3-6 итераций… Но есть парадокс. Для больших команд — надо чаще синхронизироваться, недельные итерации. В принципе понятно, что уйдут в сторону, но накладные расходы? Я: это чисто умозрительное решение…

Классический треугольник сделали квадратом :) time scope resources quality. Надо контролировать 2 переменных, если требования позволяют. Но никогда не больше 3 (то есть все 4 не поддаются?)

Вопросы — тоже общее.

• Как определить счастье заказчика — встречайтесь, не меньше 3 раз, будет доверие — он скажет
• Как транслировать PBL в SBL — общие слова, плывет…

Лассе Коскела (Reaktor) Specification By Example

15' Похоже, ликбезный докладл на основе отвлеченной метафоры… Посмотрим.

20' пошли цитаты и потихоньку переходим к делу

30' у меня пошли собственные мысли по теме — хорошо. Потом я понял ограничения методики в его изложении — для простых областей и кейсов…

40' сказал, что рассмотрели процесс. на самом деле формльно. перешел к ошибкам, и баяны — типа, сотрудничество нужно

TDD.

Началось все с тривиальное примера. Алгебра как простая арифметика 1+2=3 :) Против традиционного формального описания.

Ролик про разружение на уничтожение самолета, которое произошло при нагрузках свыше расчетных — успешные испытания. И вопрос, что из этого следует, про 3 вещи — specification validation verification. Кстати, в приведенном примере validation отсутствовал…

4 причины дефектов — programmer, design, req, systemic errors

Eliminate req errors — Spec by example.

Пишите пример. Я: все-таки это из серии идеального заказчика и простой задачи. Алгоритм на примерах не задать. Сложную работу формы — тоже не слишком задашь, если цели за рамками. Но как часть тестирования, проерки понимания — да полезно. Но пишет не заказчик, он — проверяет, и они дают ему гарантию понимания. Это понятная конструкция. Только писать должна команда, это получается часть разработки. А он предлагает скинуть на заказчика. Это, в целом, только местами работает. На самом деле, вопрос уровня, деления между acceptance scenario and test case. Методика это дело, похоже, смешивает.

Практика — specification workshop внутри итерации. До конца итерации — distill, и на следующей — разработка. Практика общая вообще для постановок командой (мы применяем), а не только в этой.

4 квадратика в другой разбивке. Одна ось — бизнес-технология, вторая — support coding vs critique product. Я: Какие-то странные дихотомии, почему именно такое различие? Он спросил с места, пошли ответы что зависит от контекста. В целом как-то не поняли.

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

Вопрос… Обеспечить взаимопонимание… Отчвет — Общайтесь с заказчиком, чем чаще, чем лучше, может быть раз в неделю, может даже два… Я: Вобщем-то правильно. Но очень обще. И это — характерно для доклада.

В общем-то народ в вопросах скорее делился своим опытом. Некоторые даже в вопросы не переходили.

Мадс Кристенсен (Microsoft) Writing HTML5 applications using ASP.NET

С докладом получилась проблема. Второй доклад в 2-часовом слоте. Технический или воспринимаемый так, поэтому интересный не всем.

Наверное, по HTML5 можно сделать концептуальный общезначимый доклад, и я даже на ADD-2010 видел похожий (ссылка). Но этот доклад — весьма сумбурный, во многом — поток слабосвязанных мыслей. Увы!

W3C — в мае 2011 прекращает прием предложений, и до 2014 года стабилизирует!

15' всякая общие вещи. Дальше перешел к конкретным возможностям — как мозаика, без концепций.

Идея — html5 — зонтик для списка разнородных технологий. И именно так представлялось.

Был живой пример — собственный сайт, куда каждый день выкладывается новая фотография. Но сайт весьма примтивный и не слишком понятно, что именно иллюстрирует. Потому что там блохи, мелочи. Которые, скорее. были бы уместны тем, кто на коленке делает собственный сайт, а не профессионалам. Да и на коленке те, кто заморачивается — гораздо более сложные конструкции делают. Хотя некоторые фонты и повороты — которых не было раньше, причем с учетом конкретных броузеров… Частные штуки никуда не уйдут, хотя чсто-то в стандарт и провалится.

А еще это местами антиреклама — if и структурные операторы внутри html, обрамленные <% %>… Конечно, разработчики и это съедят — а что им делать. Но на мой взгляд, это наглядная иллюстрация того. что у бюрократии разум спит беспробудно и неизбежно рождает чудовищ. Да еще копирайтеры проявились — стандартизаторы не смогли договорить вендоров на использование единого видео-формата, для каждого броузера надо подкладывать видео файл в своем формате!

Сергей Авдошин (ГУ ВШЭ) Формирование современных образовательных стандартов в области программной инженерии: факторы влияния

Доклад был о формировании образовательных стандартов и я пошел потому, что на параллельный доклад по ASP.NET точно не хотел, особенно услышав того же докладчика на HTML5. Докладчик рассказывал про тенденции международной (не российской!) бюрократии в области образовательных стандартов ИТ. Материалом владее. Я слушал для общего представления, делал заметки, параллельно оформлял отчет.

Вместе с Тереховым занимаются стандартами образования у нас. Основывают на SVEbok. Нужна международная аккредитация. Програмная инженирия вписывается в общую системную инженерию.

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

Сертификация в международном масштабе цветет и пахнет. В России не слишком, что докладчика огорчает, а меня радует — пока не успели, хотя особых надежд, что оно рухнет — я не испытываю. Флагман у нас по многим вопросам — IBS.

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

Проф.стандарты АП КИТ — используют. Программиста и Системного архитектора.

Совместная программа с университетом Eindhoven (там работал Дейкстра) — два магистерских диплома. Что важно — для студента бесплатно и даже со стипендией, хотя себестоимость 17т евро. Вообще университет — базовый для Phillips. Практически, думаю, таким образом привлекают наши кадры… А для них (ВШЭ) — это способ доступа к исследованиям мирового уровня, в России этого нет.

Опять про журнал Програмная инженирия, ВАК.

Юрий Шиляев (EPAM Systems) Программа обучения на 50 000 человеко-часов или как отстроить образовательную программу в ИТ-компании

История. Он пару лет назад услышал про обучение в EPAM, он и Петелин там еще не работали. Слушатели не верили про бесплатное обучение без обязанностей. Думали, что будут ломиться на обучение и уходить. По факту — нет, люди не ломятся. Теперь он руководит программой обучения (Петелин — его руководитель).

Нанимают студенты — других кадров нет. 600 за год. Проводят кучу тренингов — чтобы работало. Компания в компании, внутренний заказ на обучение — вместе с Петелиным.

Есть -

• Open тренинг — придти может кто угодно по регистрации. Например, по SCRUM
• Workshop — когда надо обучить команду, может тому же scrum.
• Менторинг-программы.

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

Тренинги для менторов и лекторов — эта отдельная программа подготовки.

Самое сложное — вырвать менторов из продуктивити. Они же реально заняты в проектах, они опытные. Но они нашли способом, каким образом ментор и менти остаются в продуктивити. Но при этом нужен постоянный прессинг куратора — продолжайте обучение, иначе свалимваются в производство.

Программа — реально длинная, 8-9 месяцев. Для менти в программе минимум 8 часов, плюс 6 — выполнение заданий. И все в личное время, за это время не платят зарплату! Как университет. Никто в эту программу никого не тянет.

Цикл Деминга Шухарда 1940-х — о котором все забыли, инкапсулировав в современные практики.

Сетевой график занятости групп и сотрудников. Динамика… Плюсы и минусы. Видно, например, когда куратор ушла в отпуск.

Квартальные периоды запуска и обратной связи. В том числе на менеджеров.

Как делать

• Найдите людей. Люди, которые хотят — есть.
• Сделайте тренинг для тернеров
• Найдите ответ — зачем тренеру этим заниматься
• Принципы
  • Все читают тренинги, и менеджеры тоже
  • Шире охват, вебинары с записью
  • Думайте как сделать больше. Каменный век кончился не потому, что кончились камни.

Тренинг — короткая программа, день-два. В отличие от менторинга, который длительный. Хорошо, когда ментор и менти из одного проекта, бывает не так, но тогда больше риски, особое внимание.

Ресурсный менеджер и руководитель проекта — иногда одно лицо, иногда разные. Решение про обучение сотрудника примнимает ресурс-менеджер.

В Белоруссии пытаются поставить образование в ВУЗах, дать заказ — Вузы отвергают, говорят нет препов.

Ольга Павлова (UsabilityLab) Менеджеры и программисты: как перестать обижаться друг на друга?

Все делятся на обобщенных менеджеров и обобщенных программистов

Обида. Дети до 2 лет не умеют обижаться. Потом учатся — это часть общества.

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

Я: тут она неправа. Корни обиды в разных целях. А дальше — интерпретация поступков в обидном смысле, по-другому… Хотя, мложет. стоит поразмышлять.

Программисты — ошибки предметны. Ошибки менеджеров — они сложно проявляются, как следствие — ненаказуемы. И потому идут обиды — виноваты всегда программисты. Я: программисты они только баги плодят, а на благо проекта не работают.

Результат работы хорошего менеджера — не заметен Я: нерпавильно. Это работа не заметна (и пример был о том же). Результат-продукт отдается команде, но менеджер то с ней :)

Ситуации обиды. Менеджер к программисту объясняет, то ему — «напиши». Обратно — программист написал (много), менеджеру некогда прочесть. «Я к тебе со всей душой…»

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

Гладить по головке — работа менеджера. Не забывайте. Остальное специалисты сделают сами.

Про ответственность. Важно его брать. Коллективный разум — безответственный. Ему свойственно думать, что высказанные идеи таинственным образом осуществяться. И многое другое.

Изменения постановок. Если пришлось менять — ответственны вы (менеджер), а не звезды. Каждый должен принять решение, что делает, а что не делает.

Если держите задачу «исправить ошибку» — делайте по-человечески.

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

Спасибо надо говорить честно, искренне чувствуя. Не провформа. И запоминать.

Защищайте программистов! Не спускать напрямую недовольство топов…

Тот, кто не хочет разбираться, но дает ценные указания — не менеджер.

Менеджер не должен кодлировать в уголке ради установления отношений — все равно не обманешь, если этого внутри нет.

Вопрос: Кто должен брать ответственность? Ответ: Тот кого заботит отсутствие обид.

Пара вопросов — мини выступлений… Типа несогласных или альтернатив. Напрмиер — что вас обиды мучают.

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

Паранойю — не лечим.

Вопрос: менеджер — начальник или лидер. Ответ — это не то и не другое. Без начальников, которых гоняют — можно обойтись. Но лидером быть не обязательно, не все склонны. Главное дать результат.