За статью спасибо, но это советы для менеджера. Для разработчика — советы не очень подходят. По пунктам:
2.1 Ни непосредственный менеджер, ни выше по иерархии — никто не может дать достаточно подробное описание задачи. Хорошо когда есть коллеги недавно работавшие непосредственно с кодом, который надо будте менять — можно проконсультироваться у них. В противном случае — читать код, анализировать качество кода, дизайна, архитектуры. Попутно можно составлять WBS и делать прототипы для уточнения оценки. Но основной навык — это чтение кода.
2.1.1 Гранулярность задач — завист от проекта. На некоторых необходима точность до часа, на других вполне приемлимы оценки вида «меньше одного дня» для простой задачи,
2.1.2 Риски для разработчика — это плохая архитектура, плохой дизайн и унаследованный код с историческими напластованиями. При проблемной архитектуре — или увеличивать период анализа и создавать полный прототип — или закладывать в риски несколько сотен процентов. Плохой дизайн кода — частичное прототипирование или до 100% на риски. Просто плохой код — 20%-40% на риски.
Фаза анализа и дизайна — есть всегда, только при работе с знакомым кодом она может занять совсем немного времени, а незнакомый код, да еще проблемный — и эта фаза может занять до 60%-70% процентов времени проекта.
2.1.3 Во первых, если гранулярность оценки задач — день и выше, то такие активности («попить кофе, почитать почту») как правило учтены. Для более мелкой гранулярности — все-таки менеджер должен уточнять, что именно его интересует — «чистые» часы или срок завершения задачи.
2.2 Не уверен, что для разработчика этот коэффициент будет иметь смысл, особенно на краткосрочных задачах. Он не учитывает влияния окружающей среды на эффективностьработы.
2.3 Я бы добавил — помните, что у менеджера и разработчика — разные понятия орисках.
2.4 В большнстве случаев мне хватает простого текстового редактора для составления списка задач, отсортированных по приоритету.
ЗЫ. Все вышесказанное — исключительно мое мнение.
Поздравляю! А www.sergelin.ru/...critics/007.asp перед покупкой столов читали?
У Феди есть опыт сваливания в контору за углом. У Феди есть репутация — сваливающего в контору за углом. Что можно получить с таким опытом и такой репутацией?
К сожалению, университеты не появляются сами по себе. Требуются значительные финансовые вливания до того как университет заработает репутацию и перейдет на самофинансирование. Стэнфорду были нужны деньги — он сдавал землю в аренду. Стэнфорду были нужны успешные выпускники поблизости — он привлекал бизнесменов которые давали работу выпускникам.
Вот только Петя, Саша и Вася уже не позовут Федю при основании стартапа — они его не знают. Зато знают друг друга, знают других ездивших в командировки.
В Америке в пятидесятые годы вопрос стоял проще — Мы переносим наши инженерные подразделения в Калифорнию. Ты переезжаешь или увольняешься?
Так и предложений таких пока что не делают. А когда начнут экономить — Феде сделают предложение: кубрик полтора на полтора в Киеве или кабинет пять на пять в Усть-Ужопинске или «хочешь прибавку — езжай в командировку» и т.д.
В той же статье:
Идея создания зоны исследований новейших технологий принадлежит Стэнфордскому университету (Stanford University). Эта идея — как всегда в Америке! — была обусловлена финансовыми соображениями: после Второй мировой войны университет столкнулся с нехваткой денег. Средства на дальнейшее развитие Стэнфорда руководство университета решило получать от свободной земли, принадлежавшей ему (3.240 гектаров), а т.к. продать эту землю было нельзя, и родилась идея — сдавать эту землю в долгосрочную аренду (сроком на 51 год) за умеренную плату компаниям, занимавшимся новыми технологическими разработками.Именно это привлекло деньги. И послужило фильтром — предложение было только для
занимавшихся новыми технологическими разработками.
Стартапы и новейшие разработки — вообще понятия перпендикулярные. Стартапы отличаются упрощенной управленческой структурой, что делает их весьма гибкими и обеспечивает высокую скорость реакции на изменения в окружающем мире.
Новейшие разработки могут основываться на многолетних исследованиях и требовать солидных капиталовложений.
Вопрос не в культуре, вопрос в бизнесе. По сравнению с Долиной, гораздо более показателен пример Голливуда: на момент основания Голливуда, земля в Калифорнии стоила значительно дешевле чем в Нью-Йорке. Это дало возможность производить нереальные для Нью-Йоркских студий съемки на натуре при сравнительно небольших бюджетах, что в свою очередь вызвало активную миграцию как кинобизнеса так и людей связанных с этим бизнесом, в Калифорнию. Долина характеризуется значительным количеством людей связанных с IT бизнесом на тысячу населения.
Для создания украинского варианта Долины требуется заинтересованность бизнеса в создании подобной диспропорции и поддержания этой диспропорции до формирования репутации местности.Крупные города и их окрестности в принципе не подходят на роль такой местности — быстро и значительно увеличить процент людей связанных с IT можно только перемещением, но для города-миллионщика переезд всех людей зарегистрированных на ДОУ увеличит долю IT специалистов всего на 2%. Для райцентра с населением в 20 тысяч аналогичный переезд даст долю в 50% IT специалистов от всего населения.
Бизнес заинтересуется в перемещении специалистов только тогда, когда будут исчерпаны возможности расширения штата и возникнет необходимость в более интенсивном использовании уже существующих ресурсов. Мудрено загнул, лучше будет на показать на примере:— Маленький городишко, половина десятого вечера, Петя, Саша и Ваня собрались после ужина обговорить проект и планы на завтра. Третья неделя в командировке, пить надоело на третий день, играть на седьмой, спать по 12 часов — к концу второй недели. Из ближайших доступных развлечений — дискотека в пятницу.
Пару лет в таких командировках и Петя, Саша и Вася привыкнут работать «много». Они станут выбирать инновационные проекты — потому что работать над ними интересно. А по деньгам владельцу бизнеса каждый из них обходится столько же сколько и Вася, работающий в офисе с наворотами в современном бизнес-центре в центре большого города.
Отсутстсвие бюджета — основной признак. Менеджер без бюджета как минимум имеет проблему в коммуникациях с вышестоящим руководством.
Аутсорсеры зачастую подписывают соглашение о неразглашении — и не могут представлять разработки сделанные для заказчиков.
Для крупных компаний обобщения вообще неприменимы — разные подразделения могут быть полными противоположностями в плане интересности работы и отношения к кадрам. В одном — мелкие задачи за которые приходится конкурировать с китайцами и индусами, жесткие дедлайны и постоянная текучка кадров; в другом — продукты которые разворачиваются на кластерах и перемалывают десятки гигабайт данных в сутки, проекты с сложной архитектурой и даже QA занимаются переученные опытнейшие администраторы переманенные у провайдеров. Но рассказывать подробности — нельзя, ведь подписано соглашение о неразглашении.
Возникло впечатление однобокости, как будто прочитал первую половину бородатого анекдота:
Не хватает:
* Вопросов охотников — Что находится между стойбищем и озером? Кто еще водится на этой территории?
* Объяснений способов охоты и разницы между ранами оставляемыми костяными и железными наконечниками копий — тут у всех кроме охотников обычно глаза становятся квадратными и стекленеет взгляд;
* Препирательств на тему неправильности употребления термина лошадь к неизвестному животному в связи с тем, что характеристики важные с точки зрения охоты ближе к мамонту чем к лошади — неправильные/неточные термины и неточность формулировок это общая проблема посредников от IT.