Первые лекции были по введению в управление проектами, а сегодняшняя, ввиду того, что многие хотели что-то про программинг, была про ООП и про решения при проектировании баз данных. Я очень рекламировал MongoDB и ругал схему EAV (с 16 слайда про EAV, а вообще там все слайды годные).

В заключение обещал опубликовать здесь задачу, для проверки уровня знаний по ООП.
Мы в FIX эту задачку отправляем некоторым кандидатам-программистам, и от качества решения зависит и предлагаемый уровень зарплаты. От студентов, которые ходят на наши лекции жду решения на (электронную почту), принимаются до 18.11.2014. Если пишете на компилируемых языках, пожалуйста, с исходником прикладывайте и бинарник, у меня нет возможности компилить вашу жаву или с++ :)

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

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

Когда играет Rnb на танцполе танцуют те, кто танцуют хип-хоп, рнб.
Когда играет Electrohuse на танцполе танцуют те, кто танцуют Electrodance.
Когда играет Поп-музыка танцуют те кто умеют танцевать под поп-музыку.
Если человек не умеет танцевать под данную музыку, он идет в бар и пьет водку.

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

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

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

Поведение персонажей следует выводить на экран текстом.

Следующее занятие 18 ноября в 15:45, в том же месте.

План — ничто, а вот планирование — наше все.

Чтобы выполнить грамотное планирование проекта нужно пройтись по шагам:

1. Разобраться что это мы вообще делаем, какой-то коробочный продукт, который сами продаем или разработку на заказ, или что-то среднее. От этого могут зависеть приоритеты, подходящая методология.
2. Определиться с тем, что внутри. Концепция, методология, требования, из которых можно составить понятное описание проекта.
3. Посмотреть на ограничения: они могут быть по бюджету, технологиям, или по срокам. Если у проекта строгий дедлайн, стоит планировать его от конца к началу.
4. Провести оценку сложности, временных затрат. Прибегнуть к мнению экспертов, других менеджеров, разработчиков. Посмотреть аналогичные продукты, прикинуть сколько времени может занять реализация подобного. Если времени на оценку много, несколько недель, попробовать спрототипировтаь какие-то элементы конечной системы, замерить сколько на это времени может уходить.
5. Оформить описание проекта с оценками сроков в виде задач в Диаграме Ганта или например в Product Backlog. Это про способ записать ваши оценки, чтобы потом, в процессе выполнения, их можно было корректировать.
6. Провести анализ рисков, внести их в список, продумать как будете понимать что риск наступил, как его утилизировать, либо передавать кому-то. Некоторые риски, случаясь, серьезно увеличивают сроки исполнения проекта. Нужно закладывать на реализацию проекта процент времени задержки по каждому риску. Пока вы не занимаетесь управлением рисками, вы находитесь в иллюзии того, что ваши первоначальные оценки верны.
   Регистр рисков в Excel.
7. Внести в список всех заинтересованных в проекте лиц, их влияние на проект, интерес. Возможно, кто-то из этих людей в списке сам окажется «ходячим риском», а какой-то — ценнейшим ресурсом, который поделится с вами важной информацией либо рисками, о которых вы не подумали.
   Регистр заинтересованных лиц.
8. Провести ревизию всего что вы напланировали, адекватные ли сроки, изменился ли бюджет, появилась ли потребность в каких-то дополнительных ресурсах?
9. Внести соответствующие изменения в план.
10. Поставить себе задачу на отдаленный срок: сохранить полезный опыт из этого проекта. Подойдут любые полезные знания: кусок какого-то плана, реестр рисков, или список лиц, пометки о том, что вам помогло или что подвело, какая методика не подошла, чьим оценкам не стоило доверять. То, что вы унесете с собой как бесценный опыт, и который потом сможете пошарить с другими коллегами.

Рекомендую книгу по управлению рисками Вальсируя с медведями.
И конечно же мастер-классы Stratoplan для всех PM-ов.

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

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

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

«Никто не пишет книги о путешествиях так, как я... Но приближается конференция TrailMix и я хочу показать всем, что такое новый шаг в развитии пеших путешествий в стиле Web! Я хочу классный сайт, на котором будет информация про меня, мои книги, будет возможность поиска маршрутов для пеших путешествий. А у посетителя должна быть возможность заказать у меня снаряжение или даже целое путешествие!».

Вопросы заказчику и последующее описание проекта нужно отправлять на (мой email)
Лучшие вопросы и описания проекта я потом опубликую.
Следующее занятие в 15:45 28 октября 2014.

Пару недель как изменил распорядок своего дня, и весьма удивлен результатами.
Рабочий день у меня начинается в 5:30: еще во время прогулки с Сэром Лойсо я читаю книгу и составляю список дел. В 7 я в офисе, а к 9:30, когда люди только начинают подтягиваться, 80% всех моих задач уже выполнено, остается дождаться каких-то результатов и совершить несколько телефонных звонков в течение дня, провести пару совещаний.

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

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

Список дел

Сейчас я использую для этого Wunderlist, сценарий использования ровно тот же, но выглядит не так костыльно как запись в блокноте TODO 20.03.2014. Вот, например, мои дела на воскресение:

Блокнот

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

Пароли

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

grep

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

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

Безкофеиновый кофе

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

Dropbox

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

Примерно год понадобился чтобы мышление перестроилось, и точка зрения на некоторые вещи изменилась.

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

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

Удивительное для меня открыте, что
Wednesday <- WOdin's day
Thursday <- Thor's day
Friday <- Freya's day

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

Между тем, 22 февраля 2014 года гигантский волк Фенрир убьёт верховного бога Одина, вслед за тем погибнут и другие боги. Далее ненасытное зубастое животное поглотит Солнце, а мир погрузится во тьму.

Что получается, когда заказчик просит сделать динамичный дизайн его сайта-визитки.
http://www.karyaclub.com/english.htm

Что делать, если вы разработчик в проекте, который заведомо потерпит крах? Если всё очень плохо, и выхода, кажется, нет? Такой вопрос задал один из пользователей в специальном разделе Stack Exchange. Мы выбрали самые интересные ответы.

Я — разработчик в команде из 5 человек, и я думаю, что наш проект движется к катастрофе. Сейчас объясню, в чём дело, но вопрос вот в чём: как я должен себя вести?

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

Что мне в этом случае делать? Мне работать больше или просто расслабиться? И что сказать менеджеру?

Причины, по которым проект близится к провалу:

1. Дедлайн скоро, а многие из первостепенных функций ещё не окончены;
2. Приложение нестабильно и сложно в использовании;
3. Система очень сложна, в коде трудно разобраться, крайне непросто вносить изменения;
4. Слишком сложная база данных (более 100 таблиц);
5. Мутное управление;
6. Почти никакого автоматизированного или модульного тестирования;
7. Никаких интеграционных тестов, хотя продукт во многом опирается на сторонние системы.
8. На самом деле, мы просто унаследовали этот проект вместе с его бардаком пару месяцев назад — до этого над ним работала другая команда во главе с тем же лидером.

Расскажите о своих сомнениях

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

У менеджеров всегда должен быть выбор, что делать; но ваш долг — оценить ситуацию и что-то донести до них. Пошлите email или оставьте записку на столе, если всё катится коту под хвост.

Сделав это, продолжайте работать над проектом с верой в лучшее.

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

Багаж знаний

Потратьте немного времени, чтобы прочесть две книги.

Death March (рус. «Путь камикадзе») — это каноническая книга, которая описывает ущербный управленческий стиль, который широко распространён в сфере разработки программного обеспечения. Из-за сжатия сроков, излишнего усложнения, бесхозяйственности многие проекты плохо заканчивают. Книга помогает понять, что вы не одиноки на этом смертельном марше. Автор Эдвард Йордон классифицирует бесперспективные проекты на 4 категории, в каждой из которых существуют разные стратегии спасения. Иногда единственный выход — просто уйти. Эта книга поможет вам выяснить, какие варианты у вас есть, и узнать, что вы можете или не можете сделать.

Catastrophe Disentanglement написана больше для менеджеров проектов. Она нацелена на то, чтобы помочь отсортировать подорванный проект: что нужно убрать, что нужно вернуть, как донести это до потребителей. «Традиционное» управление проектами часто приводит нас в тупик, и мы не сможем выбраться из него, пользуясь теми же методами. Эту книгу несколько труднее читать, чем «Путь камикадзе», но очень неплохо иметь её на книжной полке.

Останьтесь там же, но имейте варианты

1. Работайте много, но не в ущерб семье или здоровью;
2. Записывайте все критичные решения, особенно если они касаются вашей работы;
3. Продолжайте налаживать связи и имейте несколько запасных вариантов, если ситуация станет слишком сложной или вы станете жертвой массовых увольнений;
4. Попытайтесь не расценивать свой проект как провалившийся. Всем нравятся люди, которые сохраняют хороший настрой и продолжают бороться перед лицом судьбы. Так что оставайтесь таким человеком так долго, насколько это возможно. На рабочем месте всегда хороши боевой дух, мужество и решительность.
5. Если вы предчувствуете провал проекта, значит, вы предчувствуете и разбор полётов. И там каждого настигнет ответственность. Приготовьтесь защищать весь свой код. (К слову, всегда пишите код понятно, чтоб потом проще было за него отчитываться). Если у вас есть письма или фрагменты ТЗ, которые повлияли на ваши действия, тем лучше.
6. На этом разборе полётов сохраняйте бодрый настрой и обоснованно отмазывайтесь, если вас призовут к ответу.

Источник:
Как вести себя девелоперу загнивающего проекта — Цукерберг Позвонит

Год или полтора уже рассылаю знакомым книгу Славы Панкратова «Черная книга менеджера», в которой доступным языком, даже с матюками, рассказывается, в чем же заключается работа менеджера проектов, и как быть эффективным менеджером проектов. Очень рекомендую всем тимлидам и проджект-менеджерам для просветления.

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

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