• Минским архитекторам на заметку: 30 января, семинар по Web Application Architecture

    Posted on January 22nd, 2010 Александр Орлов No comments

    (Участие бесплатное при условии предварительной регистрации)

    Один из слушателей нашего октябрьского минского тренинга Владимир Лешкевич 30-го января проводит семинар-круглый стол по архитектуре веб-приложений. Если у вас есть архитекторы в Минске – обязательно их туда пошлите. Событие обещает быть весьма полезным. Чуть ниже – официальный анонс.

    При поддержке компании Intetics 30 января в Минске пройдёт профессиональный семинар-круглый стол под общей темой «Архитектура веб-приложений». В рамках семинара ведущие белорусские специалисты обсудят ряд наиболее актуальных тем в разработке веб-приложений.

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

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

    Предполагаемое количество участников: 20 человек.

    Участие в семинаре – бесплатное.

    Ведущий семинара: Владимир Лешкевич, 14 лет в индустрии разработки ПО, прошёл путь от простого разработчика до технического директора, последовательно проработав техническим лидером, менеджером проекта и архитектором ПО. Занимается обучением и коучингом проектных команд по различным технологическим направлениям и процессам разработки. Является участником и докладчиком на международных конференциях.

    Состав участников будет определяться ведущим и организаторами на основе заполненных анкет. Для того, чтобы получить возможность принять участие в семинаре, необходимо заполнить регистрационную форму по ссылке http://intetics.com/conference-registration/

  • В чем проблема?

    Posted on January 22nd, 2010 Александр Орлов 9 comments

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

    Ну, например. Релиз горит, заказчик звонит и страдает, а ты видишь, как твои бравые парни сели играть в квейк. Или там особенно небравый парень вместо того, чтобы выдавать на-гора код, читает auto.ru. Это выдержать невозможно, мозг вскипает. И ты идешь проводить воспитательную работу.

    Но есть нюанс, на который многие менеджеры, особенно начинающие внимания не обращают. начинающий менеджер начинает исправлять то, что ему не нравится. Играют на работе? Запретить играть! В аське все время чатятся? Запретить аську! Что, квейк? Шутите, что ли?

    При этом, менеджеры начинают рубить направо и налево, совершенно забывая о том, в чем, собственно проблема.

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

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

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

  • Голосование “Хотите свою компанию?”

    Posted on January 21st, 2010 Александр Орлов 6 comments

    Когда-то давно мы проводили голосование “Где вы себя видите через 3 года?”, где получилось следующее распределение голосов:

    Где вы видите себя через 3 года?

    View Results

    Loading ... Loading ...

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

    Хотите ли вы быть владельцем своей компании?

    View Results

    Loading ... Loading ...
  • Для начинающих стартаперов Сибири – конкурс 9 февраля

    Posted on January 21st, 2010 Александр Орлов No comments

    Новосибирская Школа Лидеров планирует 9-го февраля 2010 провести конкурс бизнес-планов ИТ стартапов. Видимо, я там тоже буду посажен в кругу экспертов – как раз загляну после Новосибирского тренинга. Подавайте свои заявки! Чуть ниже – официальный анонс.

    Региональный конкурс бизнес-планов и команд в области IT пройдет 9 февраля 2010 г. в рамках Школы Лидеров 2009 «От инновационной IT-идеи к бизнесу».

    Конкурс охватывает весь Сибирский федеральный округ и организован Новосибирским государственным университетом, российским отделением корпорации Intel, администрацией Новосибирской области и Сибирским отделением РАН.

    Цель Конкурса - помочь молодым предпринимателям в сфере IT опробовать свои идеи, установить деловые контакты с инвесторами  и потенциальными бизнес-партнерами, познакомиться с успешными предпринимателями, изучить проблемы и перспективы развития IT-бизнеса в нашем регионе.

    К участию приглашаются молодые IT-специалисты и IT-стартапы СФО с инновационными проектами. Приветствуется наличие прототипов предлагаемых продуктов и услуг.

    Наряду с презентациями  инновационных IT-проектов,  программа Конкурса включает в себя приглашенные доклады на актуальные темы от ведущих специалистов IT-бизнеса России.

    Победители Конкурса получат ценные призы от организаторов и партнеров мероприятия, а также сертификат участника Интерры-2010. Лучшие студенческие команды будут отобраны для бизнес-инкубирования в будущем студенческом бизнес-инкубаторе при Технопарке Новосибирского Академгородка.

    Подробности и  заявка участника - на сайте Школы  Лидеров http://leadership2009.ru/ .

  • Культуры программных проектов: часть 8

    Posted on January 21st, 2010 Александр Орлов No comments

    (все выложенные на текущий момент части – здесь)

    Конечно, существует много конкурирующих методологий, каждая из которых предписывает разные правила, стараясь захватить доминирующую позицию. Наиболее заносчивые попытались предпринять войну методологий с маркетинговой уловкой: они называют свои правила best practices. Их цель – уменьшение чувства неуютности новичков при адаптации этих правил и увеличение неуютности при адаптировании альтернатив, которые, разумеется, worse practices, из-за которых проекты проваливаются.

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

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

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

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

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

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

    Например, Ричард и Мэл были начинающими программистами в английской компании EDP. Ричард и Мэл мне сказали: «Нам не нужны никакие вонючие правила; мы просто делаем проекты». Я в этом усомнился и стал слушать разговоры в команде в течение целого дня. Вот некоторые вещи, услышанные мной:

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

    Хотя они и «просто делали проекты», они явно переняли (как оказалось, от более опытных в компании) многие обычаи, описывающие правила игры, которым они следовали без вопросов:

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

    Продолжение следует …

  • SPMGuild семинар: Самоуправляемая команда – как ее построить? (2 февраля 2010)

    Posted on January 20th, 2010 Александр Орлов No comments

    (участие бесплатное при условии предварительной регистрации)

    Локальная группа по интересам “Управление проектами в ИТ и телекоммуникациях” МО PMI и Гильдия менеджеров программных проектов представляют цикл совместных открытых семинаров по управлению проектами разработки ПО.

    Семинар “Самоуправляемая команда – как ее построить?” состоится 02 февраля 2010 г.

    Время проведения: 18:00 – 21:00

    Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117.
    Схема проезда

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

    Докладчик: Денис Петелин, признанный экспет в IT-индустрии. Известный автор и ведущий курсов по программной инженерии и управлению проектами. Свыше 3000 слушателей, в том числе из Intel, Microsoft, Yandex, Checkpoint, IBS, EPAM. Основатель и совладелец компании-разработчика и консалтинговой компании.

    Зарегистрироваться для участия

    Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC09.

  • Кризис – время делать свое дело

    Posted on January 20th, 2010 Александр Орлов No comments

    Одним из путей роста менеджера проекта, безусловно является открытие своей компании. При этом как и для любого из путей развития всегда находится куча отговорок. “А как это сделаешь, когда нет стартового капитала…” (и потом его нет до пенсии). “А где сейчас возьмешь заказы…” (вот удивительно, как же все остальные компании-то живут!) “Да какой аутсорсинг, когда сейчас толпа индусов и китайцев” (давай, давай, ной дальше…)

    На этом фоне светлым пятном показалосьнедавно опубликованное на www.it4business.ru интервью с Александром Балабановым, бывшим коллегой Славы Панкратова по Яндексу. Ребята открыли аутсорсинговую компании TestLab2, которая фокусируется на тестировании. О том, что, почему и как Александр и рассказал. Имхо, очень познавательно. Ребятам респект.

    Интервью с Александром Балабановым, директором компании TestLab2

    (Беседовал Слава Панкратов)

    Последние пару месяцев я внимательно смотрел за взлетом новой аутсорсинговой компании, которую запустил мой бывший коллега из Киева, Александр Балабанов. Пользуясь старым знакомством с Александром, я решил пригласить его дать интервью порталу www.it4busness.ru

    Интервью с Александром Балабановым, директором компании TestLab2

    Александр Балабанов, Киев, Украина. Опыт работы в IT-компаниях — больше 6 лет, приблизительно пополам в тестировании и управлении проектами. Сейчас — основатель и исполнительный директор компании TestLab2, оказывающей услуги тестирования ПО и web-сервисов: «Мы помогаем стартапам не опозориться перед инвесторами, а вендорам ПО — перед клиентами».

    Саша, привет! Расскажи о себе, каким образом ты пришел к решению открыть новую компанию в кризис, почему именно тестирование ПО и как все начиналось?
    Привет! По окончании работы в Яндексе пришло время начинать свой бизнес, реализовать идеи, которые давно не давали спокойно жить. А тестированием занялись потому, что в нем все учредители отлично разбираются, есть обширный опыт и даже свои разработки.

    Вернутся в найм не хотелось? С такой записью в резюме как «Менеджер проектов в Яндексе», я думаю, особых проблем с поиском работы быть не должно.
    Конечно, подобные мысли были. Но на тот момент (середина 2009 года) по-настоящему интересных предложений о работе просто не было. Тогда большинство IT-компаний почему-то решили, что все готовы работать за копейки, лишь бы работать. А я, подговорив пару отличных людей, решил пойти другим путем.

    А как спокойствие, комфорт, кофемашина в офисе и горячие обеды по расписанию?
    Покой нам только снится. Это все приятные мелочи, но не больше. Перспективы своего бизнеса намного интереснее, чем горячие обеды в офис. Тем более, моя жена сказочно готовит :)

    Инвестиции брали?
    Нет, стартап полностью профинансирован своими силами. Хотя, подобные мысли были, не скрою, да и возможность привлечь некоторое финансирование до сих пор есть.

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

    С чего стартовали? Как искали первых клиентов?
    Начали с документации, как водится. Описали, что хочется получить в результате, разобрались с типизацией заказчиков, попытались рассчитать финансы (planning is guessing!).

    Первых клиентов искали на разнообразных форумах разработчиков, писали шикарные персонализированные “холодные” письма. Получили пару первых небольших заказов, выполнили на 6 из 5, получили хорошие отзывы и началось.

    У тебя работают фрилансеры или люди в штате?
    Люди в штате. На данный момент удаленно, но мы все находимся в Киеве, поэтому вопрос переезда в офис – это вопрос времени. Благо, сейчас цены на аренду недвижимости вполне приемлемы.

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

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

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

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

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

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

    Для нашей команды очень важно, чтобы человек не только умел «кликать по тест-плану» но и был настоящим IT-шником, geek-ом. Как можно доверить человеку тестировать продукт, если он не знает, как работает браузер или что такое COM-модель? Для проверки этого мой коллега, Константин Кумейко, разработал анкету на ~50 вопросов, которую человек должен заполнить без какой-либо помощи, за полчаса в нашем присутствии. Это позволяет быстро оценить техническую подкованность.

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

    Как бы ты определил ключевые навыки и умения, которые должен обладать человек открывающий бизнес в сфере ИТ?
    Понимание предметной области, четкий механизм монетизации/заработка, умение выставлять приоритеты. Ну и, конечно, готовность к рискам: это очень динамичная ниша, можно быть 1-2 квартала на коне, а за последующие пол-года спустить все и прогореть.

    Экономическое образование? МВА?
    У меня лично в дипломе «прикладная математика» КНУ им. Т.Шевченко, экономике меня толком никто никогда не учил.
    Такие специализированные знания, которые дают, например в MIT Sloan’s MBA Program, безусловно, делают человека более подготовленным к ведению бизнеса или карьере в крупной компании. Но сейчас я не готов инвестировать в это два года своей жизни. Мне проще нанять консультанта или самому внимательно разобраться в какой-то узкой нише экономики или юриспруденции, чем получать обширные (ценные, безусловно) знания большинство из которых я просто не смогу нигде применить.

    Как общаетесь с заказчиками? Кто это непосредственно делает?
    Почта, Skype, телефон (собираемся накрутить кое-что с twilio), тикеты. Сейчас я выполняю функции и директора и менеджера проектов, хотя это скорее вынужденная ситуация. Все общение происходит на языке заказчика, инженеры тоже общаются с заказчиками. Хорошее знание английского языка — это обязательное требование, не хотим позориться :)

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

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

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

    На какой сегмент бизнеса вы ориентированы в первую очередь?
    На малый и средний IT-бизнес, в первую очередь, на небольшие команды разработки. Хотя, мы бы с радостью работали с Google или Microsoft, но там совсем другие правила игры.

    Насколько технологически сложны проекты, за тестирование которых вы беретесь?
    Полный набор, от простых end-user-утилит до web-проектов со сложными краулерами и логикой. С различными платформами очень повезло: опыт инженеров подобрался очень разнообразный, от привычных Win* и LAMP до работы с Oracle.

    Попадаются ли какие-то искренне интересные для вас самих проекты?
    Да, бывают и такие: например продукт для обработки результатов ночной фотоохоты за животными. Поначалу не могли поверить, что вообще существует подобная рыночная ниша. Оказалось что scouting cameras – это весьма популярный спорт в США.

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

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

    Как ты видишь своего идеального клиента?
    Пожалуй, это человек, который понимает, что мы делаем и с которым легко общаться.

    Все-таки человек или компания? Кого ты в первую очередь представляешь, когда говоришь «Заказчик»?
    Человека, с которым я веду диалог. Так всегда проще, понимать, что ты работаешь с живым человеком, у которого есть twitter, профиль в facebook и вообще жизнь за пределами заказа. Со многими заказчиками даже после окончания проекта мы продолжаем общаться, попадаются весьма интересные люди.

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

    Не хочется скатываться в «откатинг» и прочие реалии отечественного рынка.

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

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

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

    Что для этого нужно сделать?
    Не опускать ту планку качества, которую мы выставили себе сейчас. И как можно лучше работать с клиентами – тут нет предела совершенству.

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

  • Встреча Клуба Инноваторов С-Петербурга, 22 января 2010

    Posted on January 19th, 2010 Александр Орлов No comments

    (Участие бесплатное при условии предварительной регистрации)

    27-го октября 2009 года прошло первое заседание Клуба Инноваторов Санкт-Петербурга – 1-й конкурс it-проектов. В пятницу, 22 января 2010 года состоится вторая встреча Клуба. Время проведения встречи: 18:30 – 21:00. Встреча пройдет в здании Дома Молодежи, по адресу: Санкт-Петербург, Новоизмайловский пр., д.48.

    На первое мероприятие я не попал. В силу напряженного графика пролетаю и мимо второго. :) Но всем категорически рекомендую сходить, познакомиться, послушать, выступить. “Презентация в лифте” – это, если кто не понял, elevator pitch. :) Далее – текст официального анонса.

    На встрече планируется обсудить планы Клуба Инноваторов и Зворыкинского Проекта на 2010 год, рассказать о задачах и анонсировать планы. Также планируется выступление команд с проектами, формат выступления – презентация в лифте, т.е. 4 минуты на презентацию.

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

    План встречи:

    • 18:30 – 18:45. Регистрация участников.
    • 18:45 – 19:00. Приветствия со стороны организаторов, планы на год.
    • 19:00 – 19:15. Приветствия со стороны Зворыкинского Проекта, планы на год.
    • 19.15 – 20:45. Презентация авторами проектов своих проектов в режиме ЭлеваторПитч. (4 минут) Ответы на вопросы и обратная связь со стороны инвесторов и экспертов с рекомендациями по доработке проектов.(6 минут)
    • 20:45 – 21:00. Краткое подведение итогов. Анонс следующей встречи. Запись в члены Клуба Инноваторов.

    Для участия в конкурсе приглашаются все желающие. Для этого необходимо послать заявку до 21 января на e-mail: contest@htfr.org. Участие – бесплатное.

    В заявке необходимо указать:

    1.      ФИО – полностью всех людей, которые придут

    2.      E-mail

    3.      Телефон

    Для представителей проектов дополнительно необходимо указать:

    1.      Название проекта

    2.      Краткое описание проекта

    Участникам необходимо подготовить презентацию.

  • Цитата недели (Кейси Стенгел)

    Posted on January 19th, 2010 Александр Орлов 6 comments

    Суть Менеджмента – получать зарплату за то, что другие забивают голы.

  • Культуры программных проектов: часть 7

    Posted on January 18th, 2010 Александр Орлов 1 comment

    (все выложенные на текущий момент части – здесь)

    Игра по другим правилам

    Действительно ли мир полон дурных боссов? Проекты полны некомпетентных работников? Технические ребята всегда зацикливаются на своих гиковских штучках в ущерб общему успеху проекта?

    Конечно, некоторые люди могут быть довольно плохими, точно так же, как есть и супер-звёзды. В среднем же, большинство людей не будут исключительными личностями, о которых рассказывают легенды. Большинство менеджеров и членов проектных команд достаточно компетентны для выполнения хорошей работы, и у большинства вполне хорошие намерения; они делают всё в своих силах, чтобы успешно завершить проект.

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

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

    А откуда люди берут эти свои разные правила? Похоже, что ответ зависит от опытности человека.

    Начинающие: Предписанные правила

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

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

    В качестве примера такой группы правил, названной методологией, давайте заглянем в книгу Unified Software Development Process (USDP), от Booch, Jacobson и Rumbaugh, опубликованную Addison Wesley в 1998. Вот некоторые случайно выбранные правила:

    Страница 19: «При назначении ресурсов менеджер проекта должен минимизировать передачу артефактов из одних рук в другие так, чтобы ход процесса был максимально гладким.»

    Страница 34: «Разработчики начинают работу со сбора требований заказчика в виде юзкейсов. Затем они анализируют и разрабатывают систему так, чтобы она соответствовала юзкейсам, создав сперва аналитическую модель, а потом и имплементацинную модель.»

    Страница 76: «Архитектура создаётся архитектором заранее (во время фазы детализации требований). Это требует существенных предварительных затрат времени.»

    В книге сотни таких правил, а сама книга – это всего лишь подмножество более полного Rational Unified Process (RUP), который доступен по подписке.

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

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

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

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

    Продолжение следует…