Стратегия продукта подразумевает ответ — «Нет!»

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

Стратегия продукта подразумевает ответ — «Нет!»

Как следует из последней рекламы Apple, могут существовать десятки тысяч версий вашего продукта, которые могут появляться из-за разных фич, важных и неважных. Большинство из этих версий с треском провалятся и только лучшие смогут обслужить рынок. (далее…)

Детальное описание действий IT-отдела — базовый набор документации

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

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

Ниже я расскажу, зачем мы всё это сделали, и для каких случаев документ будет очень полезен. (далее…)

Корпоративная утопия коммуникационной среды

imageРабота любой крупной компании ежедневно создает информационный поток в сотни, даже если не тысячи гигабайт информации, причем зачастую по большей части повторяющейся между собой. Мы храним цитаты доброй сотни ответов в переписке, включаем зубодробительные подписи с врезкой о конфиденциальности информации. Мы храним добрый десяток версий одних и тех же документов устраивая из «базы знаний» файловую помойку. Культура информационного хранения и обмена данных сродни бытовой культуре общества. Однако, если лучших из нас еще научили не сорить на улице, то очень немногие из лучших самостоятельно научились высоко-материальной культуре. Да-да, именно научились, учить-то нас, родившихся в обнимку с компьютером, было еще некому.
(далее…)

8 вещей, которых не должен бояться разработчик

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самой распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.
(далее…)

Что это действительно значит быть «младшим программистом»

Что это действительно значит быть «младшим программистом»
Вечер пятницы, я получил имэйл от моего приятеля, который только что закончил колледж (Рочестерский Технологический Институт) и работает в весьма многообещающем стартапе, занимающемся программированием C++ систем и обучением искуственных интелектов. Ниже небольшой фрагмент его письма.

Чувак, одна вещь на работе не дает мне покоя – хотя мои коллеги по большей части приятные люди, я чувствую, как будто мою работу совершенно не ценят. Я работаю с шестью инженерами (вместе мы составляем команду из семи инженеров). Из шести, один — Platform Architect (Архитектор платформ), двое – Старших Инженеров-Прикладников, еще один – Software Architect (Программный Архитектор), остальные два отвечают за Обеспечение Качества. Если честно, и я не хочу, чтобы это прозвучало надменно, но за исключением одного Старшего Инженера-Прикладника, я понял, что знаю намного больше чем все эти «старшие» парни. Не пойми меня неправильно… они занимаются этим уже много лет, работают над важными системами и все такое, но я более образован чем они. Чаще всего, из-за того, что я Младший Системный Инженер, мои идеи просто отметаются и моя напряженная работа совершенно не ценится… откровенно говоря, это меня ужасно бесит. Иногда я подумываю о том, чтобы вернуться к фрилансу (особенно учитывая, что я уже закончил колледж). (далее…)

Закон против дискриминации в вакансиях

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

Закон в одной вакансии — вот, что работодатели указывать могут, а чего там теперь быть не должно:

Закон против дискриминации в вакансиях

P.S. Всех клиентов мы попросили привести свои вакансии в соответствие с законодательством и нашими новыми правилами. Кстати, есть список профессий (далее…)

Экзамен PMP: подготовка, аудит, рекомендации

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

Однако в процессе подготовки я понял, что информации по практическим вопросам подготовки и сдачи не достаточно, особенно по прохождению аудита.

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

Оценка удовлетворённости пользователей как способ поиска клиентов

image
На форуме, посвящённом оказанию ИТ-услуг, один аутсорсер задал вопрос, какую концепцию рекламы лучше выбрать для своего бизнеса – публикации в тематических изданиях, распространение листовок, SEO, контекстную рекламу или телемаркетинг. Ответы были банальные: главное – рекомендации, реклама ничего не даёт, а если и даёт, то только поисковая оптимизация (SEO).

В этом обсуждении меня заинтересовали два момента (помимо утверждения, что реклама ничего не даёт, но сейчас не об этом). Первое: ни топикстартер, ни участники обсуждения даже не упомянули такую маркетинговую коммуникацию, как direct mail. Наверное, потому что не видят разницы между direct mail и спамом. Второе: моя попытка донести до участников обсуждения, что концепция рекламы – это не столько способ донесения информации до целевой аудитории, сколько содержание рекламного предложения, окончилась полным провалом.

Поразмыслив, я решил, что эти вопросы заслуживают не разрозненных комментариев, а отдельной статьи. Я постараюсь не углубляться в дебри теоретизирования, а показать на конкретных примерах, как можно искать клиентов в области предоставления ИТ-услуг, используя direct mail и оригинальное по содержанию рекламное предложение.
(далее…)

Опасайтесь обобщений

Существует много модных современных концепций: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. Все они хороши. Вникание, а тем более использование, сильно расширяет горизонты. Но надо понимать, что это всё довольно общие вещи. Нужно не забывать использовать голову и чётко осознавать применимость в собственном проекте.

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

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

Где тот момент, когда они устаревают? Где те условия, в которых они работают, и в которых уже нет? Может быть, новый тренд уже стал устойчивым стереотипом и необходимо движение дальше? Эти вопросы нужно всегда задавать себе и пользоваться/не пользоваться концепцией не потому что она прогрессивна/устарела, а потому что она подходит/не подходит лично вам в конкретном деле.
(далее…)

Доказательное планирование

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

Разработчики программного обеспечения не любят составлять план работ. Обычно пытаются вовсе от него отказаться. «Закончу, когда закончу!», — говорят они, ожидая, что этот смелый и веселый поступок вызовет одобрение у босса, а о планировании будет успешно забыто.

Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»
(далее…)