Архивы для Апрель, 2012

Десант XP Injection на конференции AgileBaseCamp

Май получается очень-очень насыщенным на конференции. Одна из них на тему Agile – AgileBaseCamp CREW DRILL пройдет 25-26 мая в Харькове. Это 2 насыщенных дня:

  • индивидуальными и командными учениями
  • богатыми опытом экспертов докладами
  • дискуссиями, нетворкингом и фаном

Только в течение этой недели у вас есть шанс сэкономить до 50% стоимости билетов, собрав команду из 3-х или 5-ти человек! Зарегистрировав команду и оплатив участие до 30 апреля, вы получаете огрооомную скидку и возможность участвовать в конкурсе на самой конференции. Командных участников ждут квесты и призы.

Цены на 2-х дневную конференцию такого масштаба еще никогда не были такими низкими: 555 или 777 грн вместо 1100 гривен!

Мы высылаем туда целый десант докладчиков. Николай Алименков представит свой доклад «Continuous Delivery». В докладе Николай расскажет как построить надежный и повторяемый процесс поставки продукта, заменив большую часть ручной работы с помощью автоматизации. Речь идет не только о релизах, но также о различных демонстрациях и ручном тестировании. Слушателям будут представлены принципы и правила, которые лежат в основе Continuous Delivery (непрерывной поставки). Будет рассмотрен последовательно весь процесс внедрения полезных инженерных практик, необходимых для успешной реализации подхода, а также инструменты и библиотеки, которые помогут его реализовать.

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

Дмитрий Ефименко представит свой доклад «Auftragstaktik – старые новые принципы самоуправляемых команд». Auftragstaktik – философия управления, выработанная немецкими военными в конце XIX вв для борьбы с кризисом управления, вызванным повсеместным применением Befehlstaktik с её фокусом на выполнении детальных приказов. Новая философия управления позволила сформировать инициативный, способный к самостоятельным действиям коллектив единомышленников, объединенных общими целями. Принципы Auftragstaktik читаются как руководство по управлению Aglile командой, стартапом, продуктом. Именно поэтому, во многих современных армиях и бизнес-школах их изучают очень тщательно – они совершенно не устарели, а многие идеи и принципы прямо прописаны в наших настольных книгах.

Присоединяйтесь к нашему десанту! Будет интересно!

Как я участвовал в конференции SQADays-11

В эти выходные, 21 и 22 апреля, Киев принимал самую масштабную на просторах постсоветского пространства конференцию тестировщиков – SQADays. Конференция в Киеве стала 11-ой по счету, что уже говорит немало о ее популярности. Не смотря на мои «разработческие корни», я в очередной раз подготовил доклад на тему тестирования и принял участие в конференции в качестве докладчика. Но о моем докладе чуть позже…

В субботу меня мучала температура, поэтому я приехал практически перед официальным открытием. Тем не менее, времени вполне хватило, чтобы пообщаться со многими знакомыми. Приятно видеть на конференции столько знакомых лиц, причем из разных городов. Это отличная возможность поболтать и поделиться полезной информацией. Генеральный партнер конференции, компания Lohika, установила в холле оригинальный стенд с кислородными коктейлями. У участников появился шанс окунуться в воспоминания из детства. :)

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

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

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

Первый доклад Ярона Цубери я пропустил в пользу мини-доклада на тему советов по смене работы от Алексея Лянгузова. Леша сам только сменил работу после долгих лет, проведенных в компании Sun, и ему было чем поделиться. Много полезных советов, пометил себе эту презентацию на случай ухода с текущего насиженного места. Надо отметить, что зона стендовых докладов была оборудована грушами-подушками, которые просто мега-удобные. У меня такая есть дома. Теперь мы постараемся на следующих наших конференциях делать лаунж-зону с такими же грушами. :)

Очень хотелось проснуться, а растворимый кофе на кофе-брейке пить совершенно не хотелось. :) Поэтому мы отправились в близлежащий «Кофе-Хаус». Оказалось, там достаточно много участников конференции также коротали время. Вообще, кофе-брейки стали самым слабым местом конференции. Кипяток был на вес золота, его постоянно не хватало. Женщины в столовской одежде разливали его из большой кастрюли, заливая насыпанный в стаканчики растворимый кофе и чай в пакетиках. До еды я так ни разу и не добрался, но, по слухам, она разлеталась очень быстро. Я больше расстраивался отсутствию постоянного доступа к горячей воде, потому что мне нужно было принимать лечебные процедуры полоскания. :(

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

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

Обед я провел в компании Андрея Дзыни и Алексея Лупана. Спасибо им большое за интересную беседу, обмен идеями на будущее и просто хорошую компанию. Правда обед разочаровал. Давно я не кушал в столовках и не ощущал «столовочного сервиса». Но тут ничего не поделаешь – такое уж место проведения. Иначе бы мы просто все остались голодными. :)

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

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

Как только появится звук, я сделаю слайдкаст. Также я выложил проект, на котором я демонстрировал все примеры, на свой аккаунт на GitHub. Пользуйтесь на здоровье!

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

Первый день конференции закрывал Алексей Баранцев с темой о важности граничных значений и тестирования на границах. Мне доклад очень понравился. Тема достаточно узкая, поэтому Леша медленно и интересно ее раскрывал, с кучей классных примеров из не-IT тематики. В завершение, всех ждал мультик о «целеустремленном тестировщике», который сильно поднял настроение и стал замечательным завершением дня.

Во второй день я немного опоздал на первый доклад из-за плохого самочувствия и «попал в лапы» к Стасу Фомину. Он показал и рассказал про базу знаний, которую они собирают в компании на протяжение многих лет, продемонстрировал прогресс в его подходах к съемке и подготовке материалов, а также поведал много чего интересного. Стас – увлеченный человек и это здорово (хотя и негативно повлияло на его работу в компании)!

На второй доклад я пошел к Мишу Полярушу послушать про Robot Framework. Давно хотел посмотреть его в действии и мне это удалось. Миша показал на простых примерах как легко можно начать работать с этим инструментом и какие интересные возможности открываются перед тестировщиком. Круто, я люблю практические доклады с живыми примерами!

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

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

После обеда мой выбор пал снова на главную сцену – там два Сергея (Атрощенков и Бережной) вещали про нежелание заказчиков давать «свободу» тестировщикам. Выступление было несколько смазанным по техническим причинам – микрофоны ужасно фонили и просто не давали возможности сосредоточиться на выступлении. Идея доклада была достаточно узкой, но хорошо разжеванной – не заигрывайтесь с инструментами и подходами, а стремитесь решать выгодные с точки зрения ROI проблемы. Даже с нелюбимыми мной матрицами 2 на 2, доклад получился неплохой. :)

Следующий выбранный мной доклад, пожалуй, был единственной «ошибкой». Я отправился слушать Александра Башарина про оценки тестирования. Доклад был очень запутанный и скучный. Зато поиграли в шахматы онлайн в паре с Игорем Любиным (да, сдал с потрохами). Надо же как-то выходить из ситуации. ;)

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

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

Закрывали конференцию Наташа Руколь и Андрей Мясников. У них получился очень живой и насыщенный доклад в стиле боя в Mortal Combat. В схватке схлестнулись тестирование по сценариям и методом свободного поиска. Они наносили друг другу удары в виде аргументов и язвительных историй. То и дело зал присоединялся и выдавал свои комментарии. Отличная подача материала и, как принято, «победила дружба». Всякое тестирование важно, если его применять по месту и с умом. На этой ноте и завершилась официальная часть конференции.

За последним докладом последовало вручение призов от спонсоров и от организаторов за лучшие доклады. Очень заслуженно призы получили Олесь Сегеда, Миша Поляруш и Аня Скумина. Правда призы были несколько странными для IT-конференции – утюг, термос и еще что-то. :) Мне же в подарок досталась мышка за самое активное участие в twitter-ленте конференции. Мелочь, но приятно!

На afterparty я не попал по состоянию здоровья, поехал долечиваться. В целом, конференция понравилась. Мне посчастливилось попасть на яркие и интересные доклады, а также завести несколько полезных знакомств. Также я поделился в своем докладе наработками и мыслями на тему тестирования. А не для этого ли мы и приходим на подобные мероприятия? Надеюсь выступить на следующей SQADays-12, где бы она не проходила. Спасибо организаторам, докладчикам и участникам за отлично проведенное время!

Строим интерактивные сайты на встрече «Клуба анонимных разработчиков» 8 мая

Мы решили не откладывать в долгий ящик и провести очередную встречу клуба пораньше – 8 мая. Тем более нашлась очень интересная и «горячая» тема – построение интерактивных сайтов.

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

Дмитрий Рябко вызвался ответить на этот вопрос в своем докладе «Живые сайты – уничтожаем велосипеды». Этот доклад отражает практическое руководство создания интерактивного интернет-приложения с нуля. Основной упор будет сделан на сведение всевозможных «велосипедов» к минимуму, выводу общей концепции и выбору ключевых компонентов, как на серверной стороне, так и на клиентской стороне. В главных ролях CoffeScript, JavaScript, Python и Java.

Итак, встреча пройдет во вторник 8 мая. Место проведения мы объявим ближе к дате мероприятия. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но, по итогам прошлых встреч, есть риск, что все желающие не поместятся.

Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.

Так ли ценны менеджеры в IT?

ценность менеджеров

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

Давайте поговорим о работе IT менеджера немного детальнее. Большая часть меджеров приходит работать в компанию на готовый проект, который до этого старательно добывал для компании CEO, CTO, представитель департамента продаж или кто-то еще. Возможно, компания также принимала участие в привлечении средств для финансирования проекта. Таким образом, изначальные вложения менеджера в проект равны нулю. Теперь перейдем к набору сотрудников. Новых людей в проект ищет доблестный HR департамент, собеседовать их и принимать на работу входит в должностные обязанности менеджера, которые ему очень неплохо оплачиваются. Есть конечно редкие исключения, когда менеджер не жалеет сил и на собственном энтузиазме занимается постоением команды (в свободное время).

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

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

Вот и получается, что не за что менеджеру в IT давать возможность получать долгосрочную прибыль от своей работы в качестве наемного сотрудника. Все затраты и риски лежат на компании, поэтому прибыли и убытки также принадлежат компании. Уверен в своих силах? Классный менеджер? Дерзай! Начинай свой проект, ищи финансирование, собирай команду и работай не покладая рук! Вот тогда и обеспечишь себя долгосрочной прибылью, если конечно действительно так крут… ;)

В качестве заключения, хочу отметить, что в современном мире IT роль менеджера проектов переоценена. Ярким примером являются ведущие компании наподобие Facebook, Twitter, Instagram (как же без нее) и прочие. Они полагаются на грамотных технических специалистов и лидеров. Так что не менеджерами едиными… :)

Рубрика «Полезное чтиво». Выпуск 29

полезное чтиво

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

И порция полезного видео для просмотра:

Читайте и набирайтесь новых знаний!

Отчет о 15-ой встрече «Клуба анонимных разработчиков»

В прошлый четверг, 19 апреля, состоялась 15-ая встреча нашего «Клуба анонимных разработчиков». В этот раз уютный и полюбившийся многим офис компании DataArt принимал гостей из мира разработчиков бизнес-правил. Встреча была посвящена инструментам для разработки сложных бизнес-правил, в частности JBoss Drools.

У нас был один докладчик – Виктор Полищук, но этого оказалось предостаточно. Витя с удовольствием делился своими знаниями и опытом в использовании JBoss Drools, отвечал на многочисленные вопросы по поводу его применимости и отличиях от простой реализации бизнес-правил на языке программирования. Было очень интересно и разошлись как обычно уже после 23:00. Вот презентация этого выступления:

По просьбе участников Витя выложил проект, на примере которого он демонстрировал возможности инструмента, на github. Таким образом, участники смогут быстро попробовать его на практике и избежать проблем при начальном изучении инструмента. Также Витя поделился ссылкой на интересный проект Акинатор, который реализован на базе экспертной системы и никого не оставит равнодушным. Играйтесь на здоровье!

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

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

Следующая встреча запланирована на 17 мая и будет посвящена современной разработке с использованием JavaScript. Следите за анонсами и не пропустите начало регистрации!

Рубрика «Полезное чтиво». Выпуск 28

полезное чтиво

Праздники закончились и вас ожидает новый выпуск рубрики «Полезного чтива». Вот что накопилось за прошедшую неделю:

И порция полезного видео для просмотра:

Читайте и набирайтесь новых знаний!

Старт проекта. «Продажа» Управления Рисками?

Продолжаю серию статей «Старт проекта». Первая статья здесь – Старт проекта. Как это делать?, а вторая здесь Старт проекта. Что такое Управление Конфигурациями?

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

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

Из-за чего возникают проектные риски?

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

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

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

Скажу по себе, хотя и был много лет назад разработчиком, но когда сейчас мне нужно узнать на концептуальном уровне о каком-то техническом решении, и я слышу в ответ слова: ADO, MVC, Hibernate, XML и т.п. у меня отключаются чувства восприятия :) . Т.е. объясняющий совершенно профессионально объясняет техническое решение, но в силу разрыва понимания технологии получается недопонимание. Такие же разрывы случаются между парами тестировщик – разработчик, разработчик – менеджер проекта и т.д. И это между людьми, работающими в одном бизнесе! А что же говорить о заказчике, который хочет, чтобы мы поняли его бизнес потребности, а мы тут к нему с рисками?

Давайте посмотрим на неудачный и приемлемый варианты общения с заказчиком на этапе инициирования проекта. Беру условие практического задания «Маскировка» из тренинга «Управление рисками: классика, agile, бизнес, заказчик».

Условие:

Новый проект, примерно на год на команду 10 человек. Срок сдачи фиксирован. Требования слабо определены. Сложная предметная область. Заказчик примерно понимает приоритеты функционала, находится в США. Нужно как можно раньше четко осознать что успеется за год, т.к. нужно делать анонс продукта, продвигать и т.п. Не хватает 4 разработчика в команде, срок найма 1-2 месяца. Архитектура неясна, ориентировочно 2 подхода с разными ожиданиями по производительности, расширяемости и срокам разработки. Заказчик хочет 1-2 раза в месяц демо и прогнозы успеваемости по срокам. Прямо сейчас заказчик выбирает между 3-я поставщиками, понятно хочется выиграть заказ. Заказчик не очень техничен и от слова «риск» может «съехать».

Неудачные фразы:

  • «Мы будем работать по СКРАМу и наши разработчики вам на демо все будут рассказывать» – вы можете представить каким языком разработчики расскажут? Да и хочет ли не техничный заказчик так общаться?
  • «Мы по ходу разработки будем брать задачи из бэклога и по берндауну будем понимать наше велосити, а если не будем что-то успевать, то низкоприоритетные функции делать не будем» – несмотря на развитие гибких подходов у заказчика может случиться «вынос мозга» от такого заявления. К тому же от хочет «как можно раньше четко осознать что успеется за год».
  • «У нас есть риск недобора команды, поэтому мы нагоним потом либо овертаймами, либо сокращением бэклога» – во-первых, состав команды это не есть проблема заказчика, ему по существу все равно как вы будете делать проект. Во-вторых, от такого «подхода» сразу же веет непрофессионализмом.
  • «У нас есть риск неправильного выбора технического решения, поэтому мы заложим 20% времени на рефакторинг или имплементацию другого решения» – в понимании заказчика вы не знаете как правильно спроектировать его продукт, да еще и будете переделывать за его же деньги. И что это за мифический резерв в 20% времени?

Приемлемые варианты:

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

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

Серия статей «Старт проекта» выходит в поддержку тренинга «Успешный старт проекта», в котором темы статей рассматриваются подробнее и с практическими заданиями.

Рубрика «Полезное чтиво». Выпуск 27

полезное чтиво

В процессе выздоровления сбился рабочий ритм и я совсем забыл опубликовать очередной выпуск рубрики «Полезного чтива». Рад представить его вашему вниманию:

И порция полезного видео для просмотра:

Читайте и набирайтесь новых знаний!

15-ая встреча «Клуба анонимных разработчиков» 19 апреля

Прошлая встреча клуба, которая проходила 29 марта, получилась просто отличной – очень много полезнейшей информации, интересные доклады и классная атмосфера. Участники остались очень довольны. Следующую встречу мы решили назначить на 19 апреля.

Темой встречи мы выбрали BPM. Бизнес-процессы включает в себя ряд активностей, целенаправленно исполняемых соответствующими участниками для достижения общей цели бизнеса. Эти процессы имеют важное значение для любой организации, поскольку они могут (!!) приносить доход и часто составляют значительную часть затрат. Для программиста, практически все с чем он работает – является бизнес-моделью, а соответственно он является активным участником бизнес-процесса. Более того, код, который он пишет – это результат процесса, так как «он» решает или призван решить бизнес-проблему.

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

Главным докладчиком выступит Виктор Полищук, который расскажет о JBoss Drools и о практическом его применении. Drools является реализацией движка правил на основе Рете (Rete) алгоритма Чарльза Форджи. Адаптация Rete к объектно-ориентированному подходу обеспечивает более естественное выражение бизнес-правил и связи с бизнес-объектами. Drools написан на Java, но может работать на Java и .NET.

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

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

Итак, встреча пройдет в четверг 19 апреля. Место проведения мы объявим ближе к дате мероприятия. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но, по итогам прошлых встреч, есть риск, что все желающие не поместятся.

Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.