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

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

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

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



Сергей Белоусов: «Мы инвестируем в компании не больше 5 млн долларов. Это не значит, что бизнес, которому нужно больше денег, плохой. К нам не раз приходили люди с просьбами вложить 10 или 100 млн долларов, но мы отказывали. Иногда зря»

Для российского ИТ-рынка Сергей Белоусов — личность легендарная. Его очень краткая биография выглядит так: бизнесом начал заниматься еще студентом Московского физико-технического института, после выпуска с партнером организовал производство телевизоров, основал компанию Rolsen. Далее было сотрудничество с американской софтверной компанией Solomon, создание в Сингапуре SWsoft, позже превратившейся во всемирно известные Parallels, Acronis и Acumatica.

— Есть много различных моделей предпринимательства, я занимаюсь самой мучительной — создаю множество средних бизнесов, — признается Белоусов. — В фильме «Социальная сеть» звучала мысль: лучше поймать одного марлина, чем много форелей. Мне, к сожалению, приходится ловить много форелей. За свою карьеру я основал пару десятков компаний, и самые крупные из них — Rolsen, Acronis и Parallels — по выручке далеко не Facebook.

Добрый вечер, созидающая часть Хабра!

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

Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!



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

Введение

Думаю, многие из вас слышали выражение «9 женщин не могут родить ребёнка за 1 месяц!». Контекст этого выражения очевиден — в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.


Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости…
Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

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

Есть на свете много профессий, для которых критически важно уметь хорошо запоминать информацию. Ну, например, разведчики, лингвисты или детективы (добавьте свой вариант). Но мне кажется есть и другой класс профессий — те, кому не менее важно уметь хорошо забывать. И IT-специалист — одна из таких профессий. Аргументация под катом.

В начале прошлой недели заехал в Москву на конференцию Whale Rider.

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

Мои тезисы можно почитать в блоге, а презентацию посмотреть ниже.

Несколько слов о других докладчиках

Я был далеко не на всех докладах. Я редко прихожу послушать именно сам доклад. Самое интересное можно выяснить только в личной беседе за бутербродом и чаем. «В кулуарах».

Конфуций сказал однажды: «умный человек учится на своём опыте, мудрец — на чужом». В этой статье я постараюсь сделать ещё один шаг в направлении к «умному человеку» и поделиться, как можно аккумулировать свой опыт в течение проекта.

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

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