CustisWiki - Новые страницы [ru]

Автоматизация, как естественный процесс эволюции проекта (Екатерина Несмелова, UTD-2012)

2012-09-27T17:34:09Z

StasFomin: /* Примечания и отзывы */

Exploratory Testing. Что это? (Андрей Дзыня, UTD-2012)

2012-09-27T17:23:44Z

StasFomin: /* Слайды = */

Agile Testing - What is this anyways? (Markus Gärtner, UTD-2012)

2012-09-27T17:14:18Z

StasFomin: /* Примечания и отзывы */

Да перестаньте уже автоматизировать! (Алексей Лупан, UTD-2012)

2012-09-27T16:37:50Z

StasFomin: /* Примечания и отзывы */

Да перестаньте уже автоматизировать! (Алексей Лупан, UTD-2012)

UTD-2012

2012-09-27T16:01:02Z

StasFomin: Новая страница: «Записи первого трека конференции [http://uatestingdays.com/ Ukrainian Testing Days] [[Категория:Конференции (...»

Записи первого трека конференции Ukrainian Testing Days

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «UTD-2012»

Подбор топ-менеджера — процедура ювелирная

2012-09-27T14:30:44Z

AlexandraVelyaninova: переименовал Подбор топ-менеджера - процедура ювелирная в Подбор топ-менеджера — процедура ювелирная

Евгения Удалова: Руководитель службы персонала CUSTIS

Интервью опубликовано в журнале «Служба кадров и персонал», № 10-2011.

СК: Не секрет, что хороший топ на дороге не валяется. Есть ли дефицит топов вообще — в каких отраслях, в каких направлениях? В вашей компании — в частности?

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

Прокомментирую подробнее.

Есть целый спектр требований и ожиданий компании:

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

В разные периоды компании могут быть нужны разные варианты и комбинации этих качеств.

Привлекательность компании для топа, как правило, зависит от:

общего видения принципов ведения бизнеса и путей развития компании;
возможностей самореализации в этой компании;
уровня доверия к его профессионализму со стороны высшего руководства;
соответствия корпоративной культуры компании его ожиданиям.

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

СК: Как ваша компания закрывает подобные вакансии?

Е.У.: Думать о том, кто будет у руля компании, надо всегда. Значит, решать задачу надо комплексно: растить своих; налаживать общение и взаимодействие с интересными для компании профессионалами-управленцами из других компаний; формировать бренд компании, в которой им было бы интересно работать — пусть не сейчас, но, возможно, в будущем.

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

Растить своих топов, с одной стороны, благородно и правильно, а с другой — сложно и хлопотно.

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

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

Чтобы из специалиста вырастить топ-менеджера, компания должна постоянно поддерживать его заинтересованность, своевременно предоставляя новые задачи и проекты, постепенно все глубже погружая его в деятельность компании и расширяя его горизонты. Это важно для того, чтобы у него не пропала мотивация и не появилось чувство, что достигнут «потолок».

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

СК: Особенности интервью с топом: он, как правило, человек занятой и знает себе цену. Как с ним вести беседу, как долго, о чем спрашивать (и не спрашивать!), на что обращать внимание, как распознать «золотой самородок», а как — болтуна-госаппаратчика?

Е.У.: Здесь уместно ограничиться общими принципами, так как для каждого отдельного случая стратегия ведения переговоров будет разной.

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

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

Кроме того, на этой встрече вы обозначаете интерес к топу как профессионалу, «вбрасываете» информацию для размышления и анализа, даете ему возможность соотнести и оценить, может ли ваше сотрудничество быть интересно и взаимовыгодно.

Последующие встречи и их формат зависят от результатов «знакомства». На финальных этапах переговоров иногда стоит познакомить потенциального руководителя с управленческой командой компании и ее ключевыми сотрудниками. И только после этого принимать окончательное решение.

Распознать состоявшегося профессионала или подающего надежды «самородка» нам помогают следующие установки. Он должен понимать, из чего складывается управленческая деятельность и уметь держать в фокусе все важные разносторонние аспекты. Очень важно, чтобы ему было интересно продолжать развиваться самому.

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

Руководитель должен уметь анализировать пройденный путь и видеть пути усовершенствования выстроенной им структуры. Иначе он не сможет быть эффективным при проведении изменений и развитии вверяемого ему направления.

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

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

При подборе топ-менеджеров для структуризации ощущений и впечатлений мы используем код РАEI, предложенный И. Адизесом (P — Производитель, A — Администратор, E — Предприниматель и I — Интегратор). Это позволяет классифицировать и сравнивать разных соискателей друг с другом. В зависимости от контекста и задач, которые будут стоять перед топом, нужные комбинации кода могут быть разными, определение требуемой комбинации помогает нам принять решение.

СК:Чем можно заинтересовать искушенного топа — дополнительными бонусами, долей в бизнесе — лишь бы заполучить его?!

Е.У.: Если топ заинтересован исключительно в компенсации (краткосрочной или долго-срочной) — это плачевный вариант, на мой взгляд. Да, его можно «заманить», предложив дополнительный бонус или долю в бизнесе, но поможет ли это решению ваших стратегических задач по развитию компании? Останется ли он с вами в сложную пору перемен, если его интересует только бонус? Мне кажется, что если ему не интересно получение нового опыта в вашей компании и его не вдохновляют сложные задачи, требующие высокого профессионализма, то нет смысла «заманивать» его бонусами.

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

СК: Какими методами потом оцениваете эффективность топа и эффективность работы по его подбору (эйчара, агентства и т.д.)?

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

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

Первый — 3-5 месяцев работы в компании. Руководитель должен:

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

Второй — 1-1,5 года работы в компании. Должны быть достигнуты какие-то конкретные, согласованные с первым лицом, цели.

Третий — работа в компании более 1,5 года. Правильно оценивать эффективность работы топа по двум основным критериям: результаты по текущим обязательствам вверенного ему подразделения и его вклад в развитие компании в целом.

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

Репликация: База Знаний «Заказных Информ Систем» → «Подбор топ-менеджера — процедура ювелирная»

Продвижение HR-бренда в соцсетях

2012-09-26T14:02:22Z

AlexandraVelyaninova:

Евгения Удалова, руководитель службы персонала, рассказала порталу «Планета HR» об использовании социальных сетей для продвижения бренда работодателя. О чем стоит рассказывать аудитории соцсетей? Как поставить генерацию интересного контента «на поток»? Для чего нужно вовлекать в эту деятельность IT-специалистов? Обо всем этом — в материале «Вызывайте эмоции — и молодежь к вам потянется» на крупнейшем портале о кадровом рынке.

«Планета HR»: IT-компания 5G начала продвижение своего HR-бренда в социальных сетях, т. к. заинтересована в привлечении большого числа студентов и выпускников. За контент и коммуникации отвечают сотрудники отдела подбора персонала. Однако, написав несколько публикаций о возможностях стажировок в компании и днях открытых дверей, они обнаружили, что испытывают трудности с поиском новых интересных тем. Как бы вы предложили решить задачу регулярной генерации интересного контента?

Евгения Удалова: На мой взгляд, поставленную задачу нужно разделить на две части:

определить круг тем, интересных и студентам, и компании;

организовать процесс генерации контента.

Вначале стоит набросать «карту» контента:

перечислить темы, которые компания готова освещать;

выделить те из них, которые могут быть интересны студентам;

определить, какие темы может освещать сама служба персонала, а к чему необходимо привлекать технических специалистов.

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

О чем можно писать в контексте взаимодействия со студентами:

публиковать анонсы мероприятий, которые компания собирается проводить в ближайшее время, и отчеты по прошедшим событиям (например, «как у нас прошел день открытых дверей» с фотографиями и впечатлениями участников);

рассказывать, какие молодые специалисты сейчас нужны в компании, как происходит обучение и адаптация новичков; можно даже привести примеры тестовых заданий, которые компания дает на собеседовании;

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

Кроме того, можно (и нужно!) поддерживать свой HR-бренд и писать о жизни компании в целом:

рассказывать, как устроен офис и рабочие места, показывать фотографии;

если в компании используются Agile-практики, то можно живо и с иллюстрациями передать атмосферу работы, рассказать, как протекают основные процессы;

можно рассказать о подходе компании к мотивации и обучению, но не сухо, выдержками из документов по корпоративному праву, а на интересных примерах и реальных историях;

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

Студенты по достоинству оценят информацию, которая представляет практическую ценность, поэтому есть смысл публиковать заметки на технические, технологические темы или разбирать какие-то кейсы из реальных проектов. Можно завести рубрику «Профессионалы рекомендуют», где специалисты-практики будут советовать интересные и полезные книги IT-тематики. Если сотрудники компании выступают на конференциях, то презентации или видео с мероприятий могут стать отличным материалом для публикации, который еще к тому же демонстрирует, что в компании работают настоящие профессионалы, известные и признанные и за пределами компании.

Теперь несколько слов о том, как должен быть организован процесс.

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

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

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

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

Важно следить за качеством материала и его соответствием общей стилистике — здесь неоценимую помощь может оказать PR-менеджер.

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

Репликация: База Знаний «Заказных Информ Систем» → «Продвижение HR-бренда в соцсетях»

Внутреннее обучение: слагаемые успеха

2012-09-18T15:08:19Z

AlexandraVelyaninova:

На портале «Планета HR» опубликован комментарий руководителя службы персонала Евгении Удаловой о том, как следует подходить к внутреннему обучению. С чего начать, запуская программу обучения новых сотрудников? Каким вопросам стоит уделить особое внимание? Почему так важно заручиться реальной поддержкой руководителей? Об этом — в материале на крупнейшем портале, посвященном Human Resources. Мы публикуем полную версию комментария Евгении.

«Планета HR»: Розничная сеть QQ активно расширяется и открывает новые торговые точки. На позицию продавец планируется набор молодых людей без опыта работы в торговле, которым предлагается в течение месяца пройти программу адаптации и обучения (первая неделя чисто учебная, далее — на рабочем месте). Каковы, на ваш взгляд, необходимые составляющие успешной программы вводного обучения?

Евгения Удалова: Можно выделить несколько слагаемых успеха:

для реализации задачи использовать проектный подход (определить конкретные цели, сроки и бюджет);
уделить максимум внимания содержательной, а не административной части, на которой частенько «зацикливаются» HR-отделы компаний.

Начинать нужно с целей: описать, каким нам видится оптимальный результат, которого мы хотим достичь по завершении программы адаптации и обучения. Важно продумать как качественные требования (какими знаниями и умениями должны обладать сотрудники после обучающей программы), так и количественные характеристики (при каких результатах мы будем считать программу успешной: например, если мы возьмем на работу 80% «стажеров», принятых на обучение). Также не будет лишним через некоторое время (например, спустя полгода и год) оценить степень «приживаемости» персонала после такой программы, ведь компанию QQ могут начать использовать как поставщика учебных курсов, даже не рассматривая ее как потенциального работодателя.

Итак, на данном этапе организаторы программы должны четко понимать:

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

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

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

Если позволяют бюджет и сроки проекта, нужно тщательно подготовить будущих наставников, которым предстоит обучать «стажеров» на рабочем месте. Как минимум, стоит провести разъяснительную беседу о целях и задачах обучения, возможных подходах и т. д. В идеале нужно провести отбор и обучение наставников, ведь не каждый ведущий или просто опытный специалист может и хочет заниматься обучением.

Есть и минимальные, «гигиенические» требования, без которых проект компании QQ вряд ли будет успешным:

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Внутреннее обучение: слагаемые успеха»

Системы, которых должен знать каждый QA (Стас Фомин на встрече MSTC 2012-12-16)

2012-08-30T12:31:07Z

StasFomin:

Докладчик: Стас Фомин.

Краткая выжимка

Весьма распространено мнение, что тестировщик является всего лишь необязательным помощником разработчика, и соответственно, он должен проводить все время в тестировании готового продукта, держа себя подальше от «кухни» разработки:

репозиториев исходного кода (вотчина программистов),

хранилищ документации и требований (город серьезных аналитиков, архитекторов, юзабилистов),

систем планирования и управления задачами (зона менеджеров).

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

Можно примерять различные модели командной работы и типологии личности (модели Адизеса, Белбина, Юнга), и во всех случаях, тестировщики («Администраторы» по Адизесу, и «Контроллеры» по Юнгу), равнозначно комплиментарны программистам («Производителям» и «Предпринимателям» по Адизесу, «Анализаторам» и «Моторам» по Юнгу). Если программисты ориентированы на прорыв, риски и глобальные выигрыши (иначе это слабые, негодные программисты), на поиск наиболее экономичных стратегий реализации, то именно QA должны ограничивать эти процессы, страхуясь от рисков потери временных ресурсов (waste времени, кода) и потери потребителя (срыв сроков, нарушение требований, неудовлетворенность пользователя). ---
И в ситуации, когда тестировщики не имеют иерархических преимуществ («менеджер проекта=QA»), самый эффективный из конструктивных и неконфликтных путей системного контроля качества разработки, это создание и управление инфраструктурой разработки, такой, что не сильно затруднит, и даже поможет работе программиста, и при этом даст возможность QA-специалистам держать контроль над процессом — страхуясь от различных программистких рисков («потеря кода», «сброс кодовых бомб», «неизлечимо завшивевший багами код» …).
Это выглядит нескольно нонсенсом — разве не система контроля версий является инструментом программистов и только их самих? Увы, нет — предоставленные сами себе, программисты вполне могут разменять перечисленные риски на дополнительные проценты личной эффективности, и например, вместо централизованной VCS с защищенным системой непрерывной интеграции^[1] основным стволом разработки, будут пользоваться партизанскими распределенными репозиториями на своих ноутбуках. Также не в их интересах учет трудозатрат, задач, трекинг ошибок. Так что вполне вероятен вариант, что в новой команде (или сильно запущенной старой), будут отсутствовать ключевые системы поддержки грамотной разработки, и если вы QA — то мягко и эволюционно внедрить их — это ваш цивилизационный долг, бремя белого человека. К тому же, сейчас опять-таки, часто нет границы по навыкам между программистом, и продвинутым тестировщиком-автоматизатором, — последний вполне может быть «круче» первого в программировании, и вся инфраструктура поддержки разработки нужна и тестировщику напрямую.
Далее, в современной разработке все чаще стираются границы между аналитиками и тестировщиками (ну и сонмом смежных профессий — техническими писателями, внедренцами, техподдержкой). Соответственно, продвинутый тестировщик также должен владеть технологиями эффективной коллаборативной работы над требованиями и пользовательской документацией (границы между требованиями, пользовательской документацией и тестовыми сценариями — весьма и весьма условна). Значит, он также должен знать и разбираться групповых инструментах и для этих задач, также, как и в случая с программистами, борясь с рисками потери требований и прочих знаний.
Конечно, раньше, выбор инфраструктуры был прерогативной менеджмента, но часто это приводило к жутко неоптимальному выбору («Корпоративный стандарт управления версиями = СистемаМонстр™»), демотивирующему программистов, и современный менеджер скорее коммуникатор/психолог, а технические вопросы оставляет на выбор команде.
Таким образом, тестировщикам совершенно необходимо знать некий минимум эффективных систем групповой работы, которых они смогут эффективно внедрить в компании, в случае обнаружения «функциональных дыр», и при этом не прибегая к насилию. Причем минимальность и легковесность решения очень важна — ведь сложное, перегруженное лишним функционалом решение будет встречено в штыки, и сможет быть внедрено только сверху, властью менеджмента.
Таких решений (платных и бесплатных) можно придумать множество, мы же расскажем о нашем — наверняка не самом худшем, проверенным многолетним опытом и основанном на бесплатных и свободно доступных системах с открытым исходным кодом. Мы познакомимся с несколькими системами групповой работы, покрывающими весь спектр современной разработки, а именно, системами:

Issue-трекинга

(в нашем случае Bugzilla + Testopia) — учет задач, заданий, ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.

Вики-системой

(у нас — MediaWiki) — «универсальный швейцарский нож», подходящий для ведения документации, требований, тест-кейсов, знаний, регламентов, процессов, моделей и т.п.

Системой управления версиями

у нас Subversion — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами SVNSearcher и ViewVC.

А также узнаем, как должны интегрироваться и взаимодействовать эти (ну или аналогичные системы).

Видео

Доклады на эту тему, в общих чертах уже были и ранее, причем доступны для самостоятельного просмотра ([1], [2], [3], [4]), однако, видео с конференций смотрят мало, а лично и тем более редко кто ходит, так что ни для кого в зале это не было баяном от К.О.

↑ Continuous Integration, — концепция непрерывного тестирования по малейшему изменению в хранилище кода.

Репликация: База Знаний «Заказных Информ Систем» → «Системы, которых должен знать каждый QA (Стас Фомин на встрече MSTC 2012-12-16)»

Запад и Япония: два взгляда на бизнес-процессы

2012-08-23T13:28:48Z

AlexandraVelyaninova:

На сайте Software People опубликована статья «Запад и Япония: два взгляда на бизнес-процессы» нашего главного архитектора Максима Цепкова. Максим делится с читателями блога конференции своими мыслями о различиях европейского и японского подходов к моделированию бизнес-процессов.

Эта статья обязана своим появлением двум людям. Первый — Susumu Sasabe, который делал доклад в Киеве на конференции SQA Days, а на следующий день более трех часов отвечал на вопросы вместе с другими участниками. Слушая его и сравнивая его описания различных процессов в самых разных областях — IT, индустрии, образовании — с представлениями, которые просматривались в вопросах и ответах других участников, я смог сформулировать для себя, чем японский взгляд на процессы как таковые отличается от западного.

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

Итак, начнем.

Американцы и европейцы, когда говорят о бизнес-процессах, представляют некую исходную картину as is. Чтобы внести изменения, они проектируют желаемую картину to be, разрабатывают roadmap изменений и следуют ему. Обе картины — as is и to be — статичны во времени, то есть неявно предполагается, что бизнес-процессам присуще сохранение и воспроизведение текущего состояния, а для их изменения необходима направленная деятельность менеджера. Это, конечно, большое упрощение: всем известно, что менеджеры должны еще и поддерживать бизнес-процессы, которые, вопреки теории, не склонны оставаться в статичном состоянии. Однако, теория предполагает, что механизмы поддержки встроены в хороший бизнес-процесс, работа менеджера протекает в условиях статичных процессов, а его задачей является их изменение — перевод из одного статичного состояния в другое.

Европейский подход к моделированию бизнес-процессов

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

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

Японский взгляд на изменение бизнес-процессов

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

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

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

Теперь перейдем к визуальной метафоре.

Изменения бизнес-процессов можно представить метафорой пути: мы определяем, где находимся, описываем цель, выбираем дорогу к ней. Логично, прежде чем отправляться в путь, провести исследование и хорошо спланировать маршрут. Это, собственно, и есть европейский способ деятельности. Однако такой подход работает только в условиях достаточно комфортной местности, адекватно отображаемой на карте.

Метафора европейского пути к желаемому результату

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

Метафора японского пути к цели

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

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

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Запад и Япония: два взгляда на бизнес-процессы»

Системы Управления Версиями (семинар 2012-07-03)

2012-07-31T16:40:39Z

StasFomin: /* Видео */

Вчерашние выпускники — сегодняшние специалисты

2012-07-16T12:19:03Z

KseniyaKirillova:

Ведущие специалисты отдела персонала Дмитрий Звонарев и Евгения Лопатина поделились с порталом E-xecutive.ru своим опытом работы с молодыми специалистами. Какие они, вчерашние выпускники вузов? Готовы ли они к участию в коммерческих проектах и чем рискует компания, приглашая на работу недавнего студента? Зачем современным компаниям «молодая кровь»? Мнения HR-специалистов разных компаний — в материале «Свежая кровь: наглядное пособие для кадрового вампира». Мы публикуем полную версию комментария Дмитрия и Евгении.

Многопоточные приложения (.Net, Windows) (часть вторая) (семинар 2012-06-19)

2012-07-12T17:36:54Z

StasFomin:

Ведущий: Дутиков Михаил
Дата: 19 июня 2012

Как выстроить разработку сервиса под несколько мобильных платформ (Виктор Кузьмин, ADD-2012)

2012-06-26T19:06:23Z

StasFomin: /* Видео */

Microsoft + Node.js = LOVE! (Владимир Юнев, ADD-2012)

2012-06-26T13:58:30Z

StasFomin: /* Видео */

Высокая кухня клиентоориентированности

2012-06-26T10:11:58Z

AlexandraVelyaninova:

В журнале Intelligent Enterprise (№5/2012) опубликована статья заместителя генерального директора по стратегическим проектам Михаила Заборова и директора по маркетингу и продажам Максима Михалева, посвященная клиентоориентированной автоматизации. Как сделать процесс оказания сложной услуги по созданию (или серьезной кастомизации) масштабного ИТ-решения класса ERP максимально прозрачным и «приятным» для клиента и добиться при этом качественного результата? Как найти профессионального и ответственного подрядчика, который будет ориентироваться на интересы заказчика и доведет проект до результативного внедрения? Эти вопросы чрезвычайно остро стоят перед поставщиками и заказчиками крупных ИТ-решений, и наши специалисты предлагают свое видение проблемы и путей ее решения.

Если угождаешь, угождай каждому по-своему.
(Филип Дормер Стенхоп Честерфилд)

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

С чем это связано? Почему CIO зачастую делают все возможное, чтобы «отложить в долгий ящик» замену или внедрение крупных ИТ-компонентов? Почему сам процесс кастомизации и внедрения отнимает у бизнес- и ИТ-специалистов со стороны заказчика столько сил и времени, не гарантируя при этом качественный результат? И с чем связано то, что порой даже в случае успешного внедрения действительно нужного ИТ-решения заказчик все-таки остается недоволен?

Основы баз данных NoSQL (cеминар 2012-06-14)

2012-06-22T13:12:30Z

StasFomin:

Вирусное тестирование. Что-то новое в конфигурационном тестировании (Илья Фомин, SQADays-2011)

2012-06-21T19:28:40Z

StasFomin: /* Видео */

Управление конфигурациями и артефакты тестирования (Никита Налютин, SQADays-2011)

2012-06-21T19:13:11Z

StasFomin:

Эволюция информационной системы и логистика торговой сети (семинар 2007-05-17)

2012-06-20T16:36:49Z

StasFomin: /* Презентация */

Удаленное тестирование. Советы бывалого фрилансера (Алексей Петров, SQADays-2011)

2012-06-19T20:00:38Z

StasFomin:

ADD-2011 (Рецензии Стаса Фомина)/Техники и проблемы пэкеджинга бизнес-приложений для Windows

2012-06-19T18:30:23Z

StasFomin: Новая страница: «Техники и проблемы пэкеджинга бизнес-приложений для Windows (Павел Воронов, ADD-2011) Грустна...»

Техники и проблемы пэкеджинга бизнес-приложений для Windows (Павел Воронов, ADD-2011)

Грустная работа. Сколько сил и времени тратиться на создание совершенно бессмысленной штуки — дуратского MSI-пакета для виндового инсталлятора, пользоваться которым, из-за отсутствия batch-интерфейса и command-line интерфейса → полное мучение, с прерывающими тебя дуратскими вопросами визардами и т.п.

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

Лично я максимально ограничил использование инсталлирующихся программ, поддерживая несколько фреймворков под Bazaarом, где все софтины сделаны Portable, интегрированы друг с другом, и все это можно отлично инкрементально обновлять и в случае нецелостности — откатывать. (Похоже на http://chocolatey.org, но у меня там лежит все, под Bazaarом, включая файлы настроек).

Впрочем, для некритичных программ (которых я тоже выбираю среди open-source, или на худой конец freeware^[1], я использую http://allmyapps.com (есть аналог http://ninite.com). Вот это идея достойная,

хотя тоже пока еще не всегда и все гладко → прорываются лишние вопросы от дебильных инсталляторов.

↑ У меня десяток ноутбуков и десктопов, которыми я пользуюсь, (+обучаю и рекомендую софтины куче народу) и привязываться к чему-то (тратить свое время на обучение), за что надо платить в десятикратном размере → увольте

Удаленное тестирование с позиции работника и работодателя: Cтоит ли игра свеч? (Екатерина Жулькова, SQADays-2011)

2012-06-19T12:41:54Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://ekaterina-zhulkova.moikrug.ru/ Екатерина Жулькова] <blockquote> Как минимум ед...»

Автоматическое функциональное тестирование в рамках процесса непрерывной интеграции (Константин Жуков, SQADays-2011)

2012-06-19T12:30:10Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://ru.linkedin.com/in/kostzhukov Константин Жуков] <blockquote> Практика непреры...»

Фреймворк автотестирования веб-сервисов своими силами (Андрей Воробьев, SQADays-2011)

2012-06-19T12:19:27Z

StasFomin: /* Видео */

Автоматизация рутинных задач. Вкалывают роботы, счастлив человек! (Алексей Чумагин, SQADays-2011)

2012-06-19T11:59:32Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://a-chumagin.moikrug.ru/ Алексей Чумагин] <blockquote> В работе тестировщика ...»

Увеличиваем мощь фреймворка - KDT и генератор тестов в TestComplete (Владимир Лысенко, SQADays-2011)

2012-06-19T11:44:10Z

StasFomin: /* Видео */

Мода на мини (комментарий о мини-ЦОД)

2012-06-15T14:20:04Z

AlexandraVelyaninova:

Дмитрий Морозов, ведущий системный инженер нашей компании, рассказал «Журналу сетевых решений/LAN» о нашем опыте создания мини-ЦОД для собственных нужд. Дмитрий подробно описывает его возможности и технические характеристики, а также рассказывает о преимуществах частного ЦОД перед коммерческими решениями.

Наш мини-ЦОД — это и непосредственно центр обработки данных, и коммуникационный узел для офиса компании. Он состоит из пяти стоек. Одну занимает коммуникационное оборудование (коммутаторы и маршрутизаторы Cisco, телефонная станция Avaya), одну — система хранения данных (СХД), остальное пространство отдано под серверы и ленточную библиотеку. Каждая стойка оборудована источником бесперебойного питания.

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

Резервные копии могут храниться как в самом ЦОД, так и вне его. Бэкапы, которые могут потребоваться для быстрого восстановления, расположены на дисках СХД. Долгосрочные резервные копии шифруются, записываются на ленточные картриджи и хранятся вне мини-ЦОД (например, для максимальной безопасности — в СХД на удаленной площадке). ЦОД обеспечен круглосуточной охраной, системой контроля доступа (СКУД) и автоматической системой газового пожаротушения. Связь с Интернетом предоставляют два провайдера, ширина каждого канала — 100 Мбит/с, используется Автономная система.

Что касается стоимости «хостинга» виртуальных машин, то она (с учетом обслуживания, заработной платы обслуживающего персонала, амортизации, электричества и лицензий на программное обеспечение) оказывается значительно ниже, чем в коммерческих ЦОД. Но нельзя не отметить, что создание частного ЦОД, в отличие от использования публичного, требует крупных начальных инвестиций.

Самым важным достоинством мини-ЦОД является то, что он располагается непосредственно в офисе компании (хотя и обслуживает как внутренних, так и внешних заказчиков), управляется IT-отделом, контролируется собственной службой безопасности. Когда используется коммерческий ЦОД, мы получаем «черный ящик», по сути, полностью доверяясь провайдеру. Да, есть SLA (соглашение об уровне услуг), в котором описаны процедуры взаимодействия заказчика с провайдером ЦОД, но реальных рычагов управления он, как правило, не дает. Также нельзя проверить, какие специалисты обслуживают наши сервисы и данные. Можно ознакомиться с результатами аудита провайдера, но это не дает практически никакой гарантии, что из-за ошибочных действий его сотрудников не возникнет простоя наших бизнес-процессов.

Потому для компаний, которым критична безопасность и непрерывность бизнес-процессов, частный ЦОД обладает значительным преимуществом. А в случае, когда число средних по размерам/мощности виртуальных машин в ЦОД не превышает 1000 или нет возможности отвести под строительство ЦОД большие помещения, использование мини-ЦОД является оптимальным решением по соотношению «цена-качество». В то же время некритичные сервисы и сервисы с динамично меняющимися требованиями к ресурсам стоит переносить в глобальное облако.

В дальнейшем мы планируем увеличивать количество обслуживаемых сервисов, виртуальных машин, данных, сокращая потребление электричества и уменьшая пространство, занимаемое ЦОД.

Репликация: База Знаний «Заказных Информ Систем» → «Мода на мини (комментарий о мини-ЦОД)»

Разработка и администрирование через тестирование - облачный сервис «Битрикс24» в Амазоне (Александр Сербул, ADD-2012)

2012-06-13T14:24:28Z

StasFomin: /* Видео */

Автоматические модульные тесты при разработке корпоративного ПО

2012-06-13T13:24:23Z

AlexandraVelyaninova:

В журнале IT News (№7/2012) опубликована статья ведущего разработчика Андрея Ковалева «Автоматические модульные тесты при разработке корпоративного ПО». Андрей рассказывает, как и когда появилась идея написания автоматических тестов и какие плюсы дает их применение, а также пытается разобраться, почему, несмотря на все положительные эффекты, они так редко используются на практике.

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

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

Идея написания автоматических модульных тестов (называемых также unit-тестами) при разработке ИС появилась в 70-х годах прошлого века и была впервые реализована с помощью языка программирования Smalltalk. Однако практическое их применение при создании ИС уровня предприятия началось не так давно. Технология в ее современном виде впервые описана в методологии экстремального программирования (Extreme Programming), представленной Кентом Беком (Kent Beck) в 1999 году. Впрочем, идеи автоматизированного тестирования продолжают развиваться и по сей день. Так, например, в гибкой методологии ATDD (Acceptance Test-Driven Development) предполагается переход от модульных (unit) к приемочным (acceptance) автоматическим тестам. Остальные гибкие методологии не настолько радикальны.

В настоящее время автоматические тесты доказали свою эффективность и все чаще применяются при разработке программного обеспечения. Однако на конференции Microsoft «Платформа-2011» произошел любопытный случай. Один из ключевых докладчиков, Дэвид Чеппелл (David Chappell), обратился к залу с просьбой поднять руки тех, в чьих компаниях при разработке ПО используются автоматические модульные тесты. Таковых оказалось лишь несколько человек. Дэвид был очень удивлен и громко воскликнул: «Why?!» (корпорация Microsoft уже с 2005 года предоставляет поддержку автоматических тестов в своих инструментах для разработчика).

AnalystDays-2012 (отчет Стаса Фомина)/Король умер. Да здравствует король! Или смерть ИСО 9001

2012-06-12T20:29:25Z

StasFomin:

Король умер. Да здравствует король! Или смерть ИСО 9001 (Алексей Евменков, AnalystDays-2012)

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

Вы найдете таких только среди компаний заказной разработки и прочих ~~аутсайдеров~~ аутсорсеров (даже если они будут позиционировать себя как «game development»), либо «центров внедрения» продуктовых компаний. Можно найти эти сертификаты даже у фрилансеров из третьего мира на ODesk. Микрософту-Гуглу-Яндексу-Акронису—… все это не нужно.

И это понятно, потому что «Сертификат соответствия ГОСТ Р ИСО 9001-2008 (ISO 9001:2008)» нужен (и то, потенциально) только заказчикам (потенциальным), когда у компании нет устойчивой продуктовой репутации.

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

Собственно поэтому и новый ISO-стандарт, «специально адаптированный под разработку» никому не нужен — заказчики о нем не слышали (и славабогу), а разработчики и так его видали в белых тапках.

Мысли очевидные, даже жалко, что их старались так эффектно оформить в prezi-презентации.

Выводы же докладчика, что ISO 9001 он нужен «небольшой компании с плохо поставленными процессами», надо добавить в жирную копилку советов, «как убить стартап». Впрочем, людей из среднего размера компании (40 человек), которым эта сертификация помогла отрефлексировать процессы, я тоже знаю, см. Деньги и внутренние часы разработчика (Антон Овчинников на ADD-2010). Но и это, опять таки, аутсорсеры.

AnalystDays-2012 (отчет Стаса Фомина)/Оценивания по CMMI как… источник вдохновения

2012-06-12T20:12:13Z

StasFomin:

Оценивания по CMMI как… источник вдохновения (Александр Кондаков, AnalystDays-2012)

Некий инсайд о процессе оценки от единственного CMMI^[1]-миссионера в РФ.

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

Немного по проблемам аналитиков, которые вскрываются в ходе оценки → они, сюрпрайз, ожидаемые → то аналитики хрен пойми чем занимаются, то требования устарели, да и учится они ничему, кроме инструментов и методологий не хотят. Так что если вам нужен не «сертификат^[2]» CMMI, а «вскрытие проблем» — то я думаю, вся эта тривиальщина очевидна и без оценки.

Да и вообще, когда обсуждались результаты этих «оценок», выяснилось, что нечасто они приводят к каким-то организационным изменениям, обычно только наводят ЛПРов на некоторые мысли → это то и было вынесено в заглавие → «результаты вдохновляют». Практически «читал твиттер много думал».

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

И тут рассказали о модных западных трендах, появилась мода на Yet Another Chief Officer^[3], а именно на Chief Process Officer, ну по названию можно понять, что это. А также можно двигать в CTO, COO, OOO, … и даже становится предпринимателем, но, тут же заметил докладчик, последнее светит только на западе.

↑ CMMI-это такое четырехбуквенно заклинание, упоминание которого в блоге гарантированно призывает автора этого доклада. Понятно, что никакой мистики, просто настроенный RSS из яндексового поиска по блогам, но все же забавно.
↑ Да, я знаю, что оценка не есть сертификация, но who cares.
↑ О сколько их, Chief Lulz Officer, Chief Cleaning Officer, … ну почти как линейные структуры консалтинговых контор, где кроме верхушки — владельцев и партнеров, почти все остальные Vice Presidents

AnalystDays-2012 (отчет Стаса Фомина)/DDD — правильный курс в потоке изменений требований

2012-06-12T19:49:39Z

StasFomin:

DDD — правильный курс в потоке изменений требований (Валентина Ломаева, AnalystDays-2012)

Cначала было немного «DDD для чайников» и даже скорее вообще, адаптация для школьников, «ДетГиз», но потом пошел рассказ о реальный кейсе, пара лет работы с с огромной конторой, и с 100% плавающим всем → заинтересованными сторонами (политика), требованиями (не было даже законодательства на требуемую тему), и если честно, все это время не было даже договора на разработку.

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

Тут конечно, надо смотреть-читать непосредственно автора этой модели:

AnalystDays-2012 (отчет Стаса Фомина)/DDD и развитие аналитиков. Есть контакт!

2012-06-12T19:30:23Z

StasFomin: Новая страница: «DDD и развитие аналитиков. Есть контакт! (Анна Рид, AnalystDays-2012) Несколько сумбурный доклад...»

DDD и развитие аналитиков. Есть контакт! (Анна Рид, AnalystDays-2012)

Несколько сумбурный доклад, о том, что если компания практикует Domain Driven Design, а по большому счету, трехбуквенный фетиш DDD тут не важен, важно, что работа идет с единой целостной моделью предметной области, а не бардак с встречными потоками бумажек от на разных уровнях от аналитики до разработки, то хорошо будет не только разработчикам, аналитикам и заказчикам, но даже HRам.

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

По ходу доклада постоянно упоминались какие-то мистические «артефакты», я так понял, это представление модели предметной области в документах и диаграммах.

AnalystDays-2012 (отчет Стаса Фомина)/911, или какие пожары линейной оргструктуры доверяют тушить бизнес-аналитику

2012-06-12T18:59:16Z

StasFomin: переименовал Рецензии на AnalystDays-2012/911, или какие пожары линейной оргструктуры доверяют тушить бизнес-аналитику в [[AnalystDays-2012 (отчет Стаса...

911, или какие пожары линейной оргструктуры доверяют тушить бизнес-аналитику (Екатерина Тупчик, AnalystDays-2012)

Классическое представление о бизнес-аналитике в IT-мире, это роль в заказной разработке, обычно более близкая к заказчику, чем системный аналитик, и даже сидящая на его стороне. Т.е. идет автоматизация, бизнес-аналитики передают с олимпа бизнес-пиплов требования в трюм, для системных аналитиков, далее все падает ниже, на архитекторов и разработчиков, но на выходе цель → автоматизированная система Учета Чего-то там.

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

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

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

Об этом и рассказ. С одной стороны — нервно, с другой — уникальный опыт полевой работы. Классическая бюрократия «управления требованиями» тут не нужна (цитата «есть в интернете куча планов которых можно скопипастить поставить оценки и забыть об этом©»), а выстраивание доверия с лицами принимающими решение — да, нужно. Впрочем, инструменты тоже хвалили, типа superiority ARISа понимаешь с опытом.

Система внутренней статистики в odnoklassniki.ru (Александр Шарак, ADD-2012)

2012-06-12T14:09:44Z

StasFomin: /* Видео */

Разработка модульных приложений с использованием стандарта OSGI на Equinox (семинар 2012-05-31)

2012-06-11T16:52:08Z

StasFomin:

Аннотация

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

Вторая, практическая, часть будет посвящена стандарту OSGi и его роли в разработке Java-приложений: здесь будет краткий экскурс в историю стандарта, рассказ об организации OSGi Alliance и, конечно же, много интересного будет рассказано о плагинной архитектуре OSGi и об управлении компонентами в реализации стандарта под названием Equinox, разработанной Eclipse Foundation. В конце семинара будет продемонстрирован пример приложения на Java, использующего Equinox.

Этот семинар интересен не только разработчикам на Java, но и всем, кто интересуется архитектурой программного обеспечения.

Видео

Репликация: База Знаний «Заказных Информ Систем» → «Разработка модульных приложений с использованием стандарта OSGI на Equinox (семинар 2012-05-31)»

[[]]

Правильная архитектура высоконагруженных решений в Windows Azure (Дмитрий Мартынов, ADD-2012)

2012-06-10T12:45:05Z

StasFomin: /* Видео */

Патентная защита оригинальных программных разработок (Михаил Радченко, ADD-2012)

2012-06-10T12:38:50Z

StasFomin: /* Видео */

Успешные IT-проекты — где стелить солому (Дмитрий Завалишин, ADD-2012)

2012-06-09T20:01:37Z

StasFomin: /* Примечания и отзывы */

Сравнение AMQP и ZeroMQ (Александр Долгарев, ADD-2012)

2012-06-09T19:51:35Z

StasFomin:

Чек-лист для разработчика. О чем нужно не забыть, создавая мобильное приложение (Денис Коновалов, ADD-2012)

2012-06-09T19:41:17Z

StasFomin: /* Видео */

Как разработать вычислительную инфраструктуру для большого кластера (Евгений Кирпичев, ADD-2012)

2012-06-09T19:11:46Z

StasFomin:

Практический опыт использования некоторых современных решений репликации MySQL (Александр Чистяков, ADD-2012)

2012-06-09T18:51:55Z

StasFomin: Новая страница: «== Аннотация == Категория:Александр Чистяков ;Докладчик: [[:Категория:Александр Чистяков...»

Jabber как инструмент разработчика. Continious Integration по протоколу XMPP (Виктор Стрелков, ADD-2012)

2012-06-09T18:35:31Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://facebook.com/vsstrelkov Виктор Стрелков] <blockquote> В современном мире по...»

Пишем самый быстрый хэш для кэширования данных (Роман Елизаров, ADD-2012)

2012-06-09T18:08:04Z

StasFomin: Новая страница: «== Аннотация == Категория:Роман Елизаров ;Докладчик: [[:Категория:Роман Елизаров|Роман Ел...»

От ошибки до уязвимости один шаг (Алексей Синцов, ADD-2012)

2012-06-09T17:16:17Z

StasFomin:

Правда и вымысел расхожих представлений о хороших интерфейсах (Иван Михайлов, ADD-2012)

2012-06-09T16:12:23Z

StasFomin: Новая страница: «== Аннотация == Категория:Иван Михайлов ;Докладчик: [[:Категория:Иван Михайлов|Иван Михай...»

Картография в Windows Phone (Александр Сороколетов, ADD-2012)

2012-06-09T15:41:09Z

StasFomin: /* Видео */

DVCS как конвейер IT-производства (Артур Орлов, ADD-2012)

2012-06-09T15:30:44Z

IuliaVolegova:

Scala EE — миф или реальность? (Марат Ахин, ADD-2012)

2012-06-09T15:17:52Z

StasFomin: /* Примечания и отзывы */