четверг, 29 декабря 2011 г.

А нужен ли нам багтрекер?

Прочитал на днях интересный пост Сергея Мартыненко "Идеальное состояние багтрекера".

Задумался. И правда, на предыдущем проекте у нас не было тестеровщиков, не было багтрекера. 3 года. Проект нормально жил и развивался. Все обнаруженные "баги" сразу чинились. Багтрекер использовался только как KB, туда заносились те вещи, которые не планировалось чинить. Потом это использовалось и для написания Release Notes.

Но польза в багтрекере все же есть. Это своего рода хранилище артефактов, его хорошо можно использовать для анализа решений по проекту. Главное понимать, что его так можно использовать и вносить всю нужную для этого информацию в "багу": в чем именно проблема, как чинилось, где чинилось, как может зааффектить другую функциональность. А чаще происходит именно так, как у Сергея описано: это просто очередь из недоделок, состоящая в лучшем случае из описания проблем. Своего рода high-level "задачи" от тестеровщиков разработчикам.

PS вообще рекомендую подписаться на блог Сергея. Редко где я видел такое бурное обсуждение в комментах. Интересные вещи пишет.

воскресенье, 18 декабря 2011 г.

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

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

Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :)
Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)

Здесь приведу лишь те вещи, которые мне запали в мозг

Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"

Оля Павлова (@op):
"бойтесь иллюзии точной формулировки"
"заказчик - ребенок, выдаем ему игрушку как можно чаще"
"не забываем, что согласование тоже требует времени. учитываем при планировании"
"итеративная разработка? не забываем, что из конструктора сложно собрать куклу"
"планирование это не лестница - это лабиринт"
"обсуждение дороже разработки"
"нет планированию в одиночку"

Дмитрий Григорьев
"Самый главный враг планирования - срочные задачи"

Михаил Карпов
"Делаем команде приятно" - этим собственно все сказано. Миша уже запостил свой доклад
Смотреть всем :)

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

Марина Петрова
"Доверяйте своим людям"
"Собеседования только по скайпу не работают"
"все инструкции пишем для блондинок"
"все решения - только письменно"

Ирина Томилова
"делаем план тестования общедоступным, показываем его всем - есть шанс, что о вас вспомнят при изменениях"
"при планировании тестирования учитываем не только то, ЧТО сделано, но и КАК"

Дмитрий Качмар
"каждому нужно доносить информацию в доступном ему виде"
Были еще интересные тезисы - смотрим твиттер

Доклад Ивана Селиховкина был опять последним, и опять тяжело пошел.

Мой рейтинг докладов:
1 место поделили Оля Павлова и Миша Карпов
2 место Константин Горский с докладом про планирование дизайнеров и магию "зеленой кнопки" :)
3 место Дмитрий Качмар - за стремление поговорить о наболевшем :)

Яндексу большое спасибо за организацию.
Ну а те, кто не знали про мероприятие и его пропустили (вариант про "знали, но не пошли" выглядит фантастичным) начинаем следить за чириканием ya_events.

Update: появились видео и слайд-касты докладов 

четверг, 15 декабря 2011 г.

DataArt SPb IT-talk №1

Сегодня прошла первая, и я надеюсь не последняя, встреча-айтишник IT talk, проводимая компанией DataArt.

Встреча была посвящена стартапам и имела интересный формат: это был даже не доклад, а живое общение участников с Михаилом Завилейским и Романом Чернышевым.

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

Было много сказано интересного и полезного. Услышал много любопытных аналогий.
Роман: "представьте себе 3-литровую банку заполненную крупными камнями. Камни - это уже работающие проекты, лидеры рынка. Стартапы должны заполнить пустоты между камнями."

Пройдемся по тезизам и то, как я их понял.
  • "Стартапы как дети, и их надо любить." Почему? А почему любят детей? - они наше будущее.
  • Экономисты говорят о «потерянном десятилетии» - к черту голубые фишки, надо вкладываться в стартапы :) Тут прозвучал забавный термин "вафлинг" - так описывается период подъемов и спадов.
  • "Ежи-буддисты и лисы-серферы. Такие разные предприниматели, черт их побери…" - Михаил и в этой встрече использовал свою любимую аналогию про ежей и лис. Поспорили про то, кто может довести стартап до победы. Похоже, что это проще сделать ежику :) Напомню, первый раз я услышал это на SPMconf
  • "Русские деньги, или Особенности национальных стартапов" - все хотят делать здесь то, что сработало на Западе: там сработало, а почему здесь не пойдет?
  • "Лидеры, адепты и седьмая вода на киселе" - с большой вероятностью придется решать проблему отхода от дел основателя стартапа: расширение, смена основной активности в стартапе. Все это приводит к тому, что до момента "выстрела" "доживают" не все сотрудники, которые начинали стартап. И это может быть проблемой.
  • "Пока не началось, или Затяжки с началом операций" - стартап не должен залеживаться. Понять, что реально нужно пользователям, можно только показав продукт пользователям (ну или родится Стивом Джобсом-Биллом Гейтсом). Подводные камни - косяки, из-за которых народ больше не придет к вашему продукту, поэтому аккуратней с первым шагом.
  • "Чтобы не было так больно. Помогает ли информационная диета держать команду в форме?" - нет, нет ограничению иноформации. Но... :) каждому нужно знать то, что можно. Взвешенно подходим к этому вопросу. Но информационный голод вызывает галюцинации у команды...
  • "Осторожно, мины. Мультисорсинг и интеграционные риски" - Задумайтесь, когда заказываете дизайном у одних, а кодинг у других. По опыту - не срастается.
  • "Стартапы и финансы. В чем отличия бизнес-проекта и бизнеса?" - бизнес-проект = програмный продукт, бизнес = компания по разработке этого продукта.
  • "Smart Money (бизнес принес идею и дал денег) – миф или реальность?" - большая редкость, но один из участников сказал, что у него вроде как наклевывается :)
  • "Лебединая песня стартапа." - собрались закрывать, а вдруг пошел клиент. Бывает и такое.
  • "Если друг оказался вдруг… Кризис финансирования, и на кого стоит рассчитывать, а на кого нет?" - чаще помогает команда (работа за хлеб), а вот инвесторы чаще прекращают финансирование.
  • "Честные, дружные, успешные. Выбери одно?" - да "чудес не бывает" (с) Максим Шульга. Всегда кто-то, где-то проигрывает, а кто-то выигрывает.
Вот как то так. Мне понравилось. Надеюсь встречи будут продолжаться. Спасибо, DataArt.

PS цитата, М.Завилейский "не пытайтесь понять картинки на слайдах, это просто culture reference" - на слайдах были фотографии ставших уже классикой картин :)

PS2 булочки с вишней были зачетные :)

Куда сходить, куда съездить, где поучиться в 2012

Близится к завершению 2011. А что год грядущий нам готовит в плане образования? Куда имеет смысл съездить, где поучаствовать, что изучить нового. Планируем заранее!
Здесь небольшая подборка того, что я нашел интересного на следующий год. На всех побывать 100% не получится, но хоть потом видео, доклады собрать. Может и вам пригодится.
Конференции:
Application Developer Days (23-24 марта, Москва). Для разработчиков и не только дляMicrosoft. Программы еще нет, но в этом году (судя по отзывам) было интересно.
Software People 2012 (10-12 апреля, Москва)
Темы:
· человеческий фактор в разработке ПО (Peopleware);
· методологии и процессы разработки ПО;
· управление проектами и управление командами технических специалистов;
· требования;
· юзабилити и UX ПО, проектирование интерфейсов;
· проектирование и архитектура;
· технологии и инструменты;
· разработка мобильных приложений;
· облачные вычисления Cloud Computing.
DevCon 12 (23-24 мая, Подмосковье) Регистрация уже открыта. Есть скидки участникам DevCon11, TechEd2011 и другие. Торопитесь, скидки до 13 февраля 2012.
Основными темами конференции DevCon’12 станут:
· Клиентская разработка;
· Мобильная разработка;
· Веб разработка;
· Облачные вычисления;
· Средства разработки и управление жизненным циклом ПО;
· Технологии разработки и языки программирования;
· Корпоративная разработка;
· Взаимодействие с другими платформами и технологиями;
TechEd Europe 2012 (June 25-29, Amsterdam) Это будет стопудово дороже, TechEd 2011 Russia (хотя бы за счет проезда). Но во-первых неделя вместо 2-х дней, во-вторых пока не ясно будет ли у нас что-нибудь в след. году. Но я конечно понимаю, что шансов мало – это больше чтобы быть в курсе, что такое есть.
VMworld Europe 2012 (October 16-18, Barcelona) ссылок пока нет, кроме постов про собственно евент от участников VMworld 2011

Тренинги:
Набор программ от клуба Стратоплан
Подумываю про курс от VMware необходимый для сертификата на VCP5, пока не решил.
Бесплатные курсы от Стенфордского университета. Для себя выбрал Design and Analysis of Algorithms и Human-Computer Interaction (сейчас уже закрыт, но можно почитать тут о других возможных вариантах "Top Online Graphic Design Courses"). Также там можно посмотреть и выбрать для себя курсы на другие темы (ссылки можно найти внизу открытой страницы, крутите до упора вниз). Может еще это послушаю: Software Engineering for Software as a Service.
Update: Коля Алименков составил "Памятку участника конференции" (часть 1, часть 2) - просто, но часто о многих вещах забывают.

пятница, 2 декабря 2011 г.

Учим Python & Ruby вместе с детьми - это просто

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

Начал я с Learn Python The Hard Way”.

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

Также в планах Learn Ruby the hard way”. Тут я пожалуй и сам поиграюсь. 25 декабря запустился интересный проект KidsRuby. Тоже будем пробовать.

А вот аналогичные странички для SQL и Regex меня не впечатлили, да и находятся они пока в стадии наполнения.

Еще интересные ресурсы c Python: pygame и отчет про обучение детей с PyCon.

Нашел еще интересные и бесплатные книжки про Python: "Invent Your Own Computer Games with Python"

Google Python class - видео лекции и текстовые материалы (англ.)

JetBrains PyCharm Educational Edition - версия популярного IDE для Python, ориентированная на обучение.

среда, 30 ноября 2011 г.

Простые правила хорошего разработчика

Первоначально этот пост планировался как перевод статьи "15 Tenets for Software Engineer". Но по мере написания становилось понятно, что в чистом виде перевод не катит. Поэтому получилось то, что получилось. Допускаю, что все это выглядит, как очередной флуд из серии "умные идеи от Капитана Очевидность", но мне статья понравилась и я постарался выразить свое мнение по данному вопросу (ниже по тексту для этого используется курсив). В конце концов, иногда очевидные вещи услышанные (прочитанные) в очередной раз, могут помочь окончательно сформировать мнение по тому или иному вопросу.

На этом месте большинство может перейти на оригинал и не терять время на попытки найти неточности в переводе - их масса :)

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

Попытаемся объединить все это.

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

  • Помнить базовые основы языка программирования. Всегда. Если ты забываешь (не будем говорить "не знаешь") эти основы, ты теряешь инструмент, без которого ты не можешь применять остальные знания и умения. Это всегда плохо. По себе могу сказать, что как только не используешь язык больше чем полгода, ты начинаешь забывать много тонкостей. Часто я использую разные языки для разных задач, это помогает освежать знания.
  • Всегда понимать, какой сценарий наихудший. Если у вам довелось изучать алгоритмы (мне, например, в военном училище это счастье не привалило), то вы знаете что означает нотация "О". Знаете, почему алгоритм не может работать лучше - хорошо. Понимаете, почему данный сценарий хуже, чем остальные - отлично. Это то, что позволит вам оставаться успешным. В реальных проектах лично мне редко случалось оценивать именно алгоритмы и выбирать из них лучший. Чаще при оценке приходится учитывать множество факторов, а не только скорость определенного алгоритма. Но почему-то на собеседованиях спрашивают именно об оценке сложности алгоритма. Поэтому, я думаю, имеет смысл поддерживать себя в тонусе и освежать теорию. Например, вот недавно наткнулся на бесплатный онлайн-курс от Стенфордского университета Design and Analysis of Algorithms.
  • Читайте, много читайте. Если вы не читаете материалы посвященные вашей сфере деятельности, то рискуете отстать от постоянно изменяющегося мира. Это может стать препятствием для вашего карьерного роста. "6 книжек которые должен прочитать каждый разработчик"
  • Проверяйте, тестируйте свой код. Добивайтесь того, чтобы у вас были тесты на ваш код, неважно следуете ли вы TDD практикам или используете другие способы. Уровень покрытия кода тестами зависит от типа тестов, но вы должны писать столько тестов, сколько можете. В качестве одного из критериев оценки необходимости написания автоматических тестов можно использовать стоимость написания и последующего запуска тестов. Думаю, есть вещи которые все же дешевле проверить руками, нежели написать тесты. В конце концов код для тестов - это тоже код, для него тоже пишем тесты? Включаем мозги и решаем, что тестируем автоматом, а что ручками. И помните, тестирование не улучшает качество, а измеряет его.
  • Не начинайте использовать новые технологии только потому, что они новые. Используйте их, если они решают вашу проблему. Часто мы следуем новым технологиям в надежде найти "серебряную пулю". Технологии это инструмент, а не волшебство.
  • Пробуйте новые практики и технологии. Постоянно. Да, выше уже говорилось, что не надо использовать новые технологии просто потому, что они новые. Но вы должны пробовать новое, хотя бы для того, чтобы определить, чем оно вам будет полезно. Это также поможет учится и быть в курсе всех последних веяний. Да это сложно, найти баланс между "использовать" и "пробовать". Чаще бывает проще взять и "заюзать", а дальше посмотрим. Не всегда у вас есть возможность сначала обкатать технологию, понять все ее плюсы и минусы, и только после этого принять решение о целесообразности ее использования. Более того, часто, эти самые плюсы и минусы можно увидеть только после реального использования в «продакшене». Но смотри следующий пункт.
  • Ошибаясь, вы учитесь. Как минимум вы поймете, что именно не работает и сможете улучшить свой продукт. В некоторых случаях вы даже можете рассматривать неудачу как маленький успех.
  • Отношение к выдаче «сырого» кода. Иногда вам нужно просто выполнить свою задачу, но вы должны понимать и оценивать оставшиеся долги (если они есть). Если вы постоянно отдаете «сырой» код и накапливаете свои долги, то это прямой путь к кошмару, который настигнет вас, когда в продукте вылезет бага.
  • Делайте «все правильно». Большинство разработчиков имеют свое представление о том, как сделать «все правильно», но не всегда это совпадает с мнением менеджера проекта. Этот пункт можно рассматривать как противоположность предыдущему пункту про выдачу «сырого» кода. Нужно пытаться удержать баланс между этим крайностями.
  • Постоянно улучшайте код: оставляйте код в лучшем состоянии, чем он был на тот момент, когда вы начали с ним работать. Вместо проповедей о достоиствах рефакторинга, подумайте, хотите ли вы поддерживать кучу кода, который становится все хуже. Если вы будете улучшать код по чуть-чуть каждый раз, когда вы его меняете, то код уже не будет ужасным. Ну или, по-крайней мере, хуже он становится точно не будет.
(Дальше идут совсем банальные вещи, но как часто я встречал случаи, когда их игнорируют...)
  • Думайте об одновременном доступе. Если вы разрабатываете веб-приложение, и разговор вовсе не идет о приложении масштаба Facebook-а, то при нагрузке могут вылезти странные вещи. Даже у приложения со 100 одновременно работающими пользователями могут возникнуть проблемы из-за параллельных операций записи и чтения например в HashMaps. И это только вершина айсберга.
  • Места на диске может быть много, но I/O операции могут тормозить. Вы можете полагать, что сохранять все на диск, это отличный способ хранения данных. В общем случае это так, но если вы используете диск как временное хранилище, ваше приложение может быстро споткнуться. Использование физического хранилища должно быть ограничено только теми случаями, когда данные нужно хранить долго, или они просто не помещаются в памяти.
  • Кэш творит чудеса, до тех пор, пока не умирает сервер. Если вы ищете способы избежать повторяющихся запросов к базе, вы начинаете использовать кэширование. Но проблема в том, что кэш требует гораздо больше памяти, чем обычно использует ваше приложение, особенно когда разговор идет о данных, размер которых увеличивается с увеличением количества пользователей. Худшее, что может случится с кэшем, это неконтролируемый рост его размера, что приводит к OutOfMemory ошибке. После этого ваш сервер или «упадет», или перестанет отвечать на запросы. И кэширование уже не поможет, так как стало частью проблемы.
  • Думай и действуй как консультант. Очень часто компании могут поступать с сотрудникам так, как не поступили бы с консультантами: сроки могут быть изменены, объем работ увеличен. И разработчик должен найти способ решить задачу с учетом изменившихся реалий. Как сотруднику, вам нужно использовать все силы для того, чтобы предупредить о том, что сроки не могут быть изменены ввиду имеющегося объема работ, или что объем работ не может быть увеличен без увеличения количества задействованных ресурсов.
  • Внимание к деталям и уважение. От себя добавлю, что хорошего разработчика отличает внимание к деталям и уважение к результату своего труда . Если ты просто генеришь строчки кода без понимания того, зачем они нужны, без проверки того, что они действительно работают - ты не можешь себя считать хорошим разработчиком. Уважение надо также проявлять к тем, кто помогает оценить качество твоей работы, тестировщикам. В конце концов задача у нас одна - получить готовый продукт достойного качества.
PS перечитав еще раз это творение, почему то вспомнился анекдот про начальника, который согласно первому пункту всегда прав, а если не прав - смотри пункт первый. Уж очень, как то, все банально получилось. Надеюсь вы тоже повеселились :)

суббота, 26 ноября 2011 г.

Первый на русском или хороший повод

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

Сегодня состоялась первая конференция Software Project Management. Организована она была компанией SQALab, у которой получилось собрать в одно время и в одном месте много умных людей с интересными идеями про то, как правильно управлять проектами в IT, как работать с командой, какие процессы и как использовать. Большое спасибо SQALab за возможность это все послушать и пообщаться с коллегами.
Итак о моих впечатлениях в целом и о тех докладах, которые удалось посетить.

Сначала о докладах.
Макс Вишнивецкий (@vishmaks). "Отдельные вопросы анатомии менеджера".
Несмотря на медицинское название разговор шел об ошибках, которые часто совершают молодые (я думаю не только молодые) менеджеры: недостаток опыта часто компенсируется (или усугубляется) горячностью, увлечением новыми технологиями и практиками. При этом только с опытом понимаешь, что знаменитые проектный треугольник PMI (бюджет, сроки, объем работ) на самом деле выглядит далеко не как треугольник, а скорее как многогранник. Макс предложил свой вариант треугольника, который, на его взгляд, отражает, как правильно работать с командой. Его составляют доверие, воспитание команды и умение ее защищать. Рассказывалось все очень увлеченно и зажигательно и сопровождалось замечательно подобранными слайдами. Я думаю, что все проснулись (доклад был первым) и получили заряд на весь день. На вопрос "нужно ли помогать менеджеру избегать ошибок" Макс ответил, что "грабли" очень полезны, более того иногда имеет смысл предлагать ему неверную подсказку на его вопросы (для получения иммунитета видимо :)

Лиля Горбачик (@Gorbachik_Lilia) "Как сохранить команду в эпоху перемен"
Доклад в целом неплохой, но без фейерверка. Рассматривались проблемы, с которыми сталкивается менеджер, когда в компании грядут перемены. Для общего развития имеет смысл посмотреть/послушать, но меня не зацепило. Из запомнившегося - "всегда надо готовится к разговору с сотрудником". Ну и уж очень часто звучала пропаганда курения, как способ успокаиваться :), хотя сама она я так понял не курит. Пообщался в кулуарах, по поводу вопросов тестирования (Лиля из QA) и взаимодействия команд разработчиков и тестеров. Она озвучила мысли совпадающие с моими, а именно что эти команды не могут быть по разные стороны баррикад - цель одна: продукт.

Вика Придатко (@nikavika) "Техническое интервью с человеческим лицом"
Вика была в ударе :) Как в общем и обычно на ее докладах. Раньше смотрел в записях - вживую круче :)
Тезисы:
"Первое впечатление второй раз не создается" (классная мысль)
Общайтесь с кандидатом, как с членом вашей команды
Слушайте людей
Всегда задавайте вопрос "что вам важно?"
Берите людей, которые обожают то, что делают
Обязателен feedback, это важно для имиджа компании
забавные вопросы для собеседования:
"Какой самый интересный вопрос вам задавали на собеседовании?" (а вдруг потом вам пригодится :))
Что вам нравится в себе?
Последнее важно не путать с "Кем вы видите себя через 5 лет?" - это булшит

Михаил Завилейский (Ген. менеджер DataArt SPb) "6 хороших идей, которые я бы не посоветовал реализовывать, пока это возможно"
Зачетный доклад, надо еще раз пересмотреть в записи
Тезисы:
- Соревнования между командами - часто больше вредит, чем помогает.
-Нужно ли доводить дело до конца? (лисы vs ежи). Лисы часто не могут доделать дело до конца, ежи всегда доделывают. Программеры почти все лисы. Интересный пример про гору с кучей трупиков ежей под ней. "Если то, что ты обещал нужно только тебе - то ты сам вправе решать нужно ли это доделывать или нет"
- Об измерениях (KPI): измерения могут изменить поведение измеряемой системы (и чуток квантовой физики для примера :) и не факт, что эти изменения будут полезны.
- Кнут vs пряник. На пряник обычно не хватает денег, так может и кнута не надо? Человек сам переживает, а если нет - то с таким расставаться. Нужно благодарить людей и делать это часто. Кстати тема благодарности команде звучала сегодня очень часто на разных докладах.

Сергей Архипенков (очень умный и суровый) "Антипаттерны командного поведения"
Какие бывают типы людей и как это нужно использовать. Пересказывать я бы не рискнул, надо просто посмотреть запись.
Из запавшего в мозг:
- Все программисты - меланхолики (интересно действительно так? Про себя бы не сказал, но я все же не до конца программист)
Надо поощрять командное поведение
"Твое ДА ничего не стоит, пока ты не говоришь НЕТ" - нужно любить людей, которые умеют отстаивать свою точку зрения.
"Ни в одном ВУЗе не учат РАБОТАТЬ"
3 признака хорошего менеджера
- приверженности проекту
- эмоциональный интеллект
- лидер умеющий видеть цели

Оля Павлова (@op) "Курс молодого бойца для менеджеров" или как жить без HR
Очень драйвовый, я бы сказал, жесткий доклад. Рекомендую.
тезисы
Искать людей надо до того, как они понадобятся
Не надо быть как все (на HH.ru работу никто не ищет, как и работников - хмм прикольно, я обычно там и делал и то, и другое)
Программисты - ауты (тут я вообще присел...)
Опять про важность обратной связи с соискателем (донести до него принятое в итоге решение)
Используешь микроменеджмент - убей себя об стену (блин, я грешил этим...)
Все это должно делаться честно и от сердца...

Асхат Уразбаев (scrumtek) "Развитие IT-организации"
Видимо я был оглушен докладом Оли, в итоге у Асхата я переваривал услышанное... Надо будет пересмотреть.

Евгения Фирсова (@diffidence) "Покажи мне свои папки"
Честно не ожидал от этого доклада такого потока полезной информации. Очень хороший докладчик и позитивная девушка в японском стиле :)
Был приведен свой набор антипаттернов, мешающих менеджеру
"Даймё" (япон.)
работа в стиле "все уже решено, согласовано и не может быть изменено". Как бороться: привлечение сторонних экспертов, "стравливание" самих даймё, обозначение рисков, если не удалось их победить.
"Рикша" - (сел к вам в коляску и свесил ножки) "вы начинайте делать, а я пока подумаю, зачем оно надо". "доступ к телу" строго по расписанию и по правилам
Как бороться: стараемся понять как он работает. И ходим, ходим, ходим - менеджер не должен сидеть.
"Чайный домик" (созерцание) - "постоянный негатив" как то я не уловил ассоциации...(Update: см. комментарий от Жени (aka Saigo) ниже, ну и слайды обязательно смотрим)
Как боремся: проговариваем проблемы вслух, всегда благодарим команду, делаем выводы на будущее...

Рома Юферев (http://a-jail.blogspot.com/) "Шарада для менеджера"
Рома отжег, мега-доклад в формате комикса (по-моему лучший доклад, из тех что я сегодня послушал). Под конец напомнило речь пастыря-евангелиста :)
Любимые отмазки менеджеров:
- А что я могу сделать?
- А что, можно было?
- А какова политика компании по этому вопросу?
Какие еще проблемы: паника, проект "сжирает".
Решение: у вас есть свобода выбора и ВОЛЯ.
"можешь свалить на Кубу, а можешь сделать свою Кубу прямо здесь" - Ты можешь изменить реальность. "Не сиди на попе ровно" :)

Иван Селиховкин (http://pmlead.ru/) "Руководитель проекта - жизнь до и после найма"
История про улей и то, как менеджер должен доказать что он пчела, а не медведь.
Важно показывать результат команды в цифрах.
Что и когда показывать:
Риски - всегда до старта проекта
данные из треугольника PMI, риски , документы - в течении всего проекта
Рекламации, снижение стоимости команды - в конце проекта
и обязательное сравнение всего этого от проекта к проекту.

Вот собственно и все, что удалось послушать и посмотреть. Было здорово пообщаться с теми, кого до этого только читал в блогах и твиттере. В конце конференции был розыгрыш ценных призов от спонсоров и организаторов. iPad2 я конечно не выиграл, но 100% скидка на любую следующую конференцию SQALab - МОЯ, за что SQALab большое спасибо.

Update: благодаря Стасу Фомину есть возможность посмотреть видео докладов