Большие беды маленьких проектов
Не знаю как у вас, а у меня уже реально наболело. Уже больше полугода занимаюсь менеджментом команды порядка 50 человек, которая пилит целый легион мелких проектов. И все бы оно ничего, но эти проекты ведут себя реально как прутики из веника - по одному вроде как и фигня с легким гемором, но когда собираются в кучу (а это происходит как минимум раз в неделю, на еженедельном статус-отчете), получается одна такая огромная, ломовая хрень, с которой приходится бороться изо дня в день. А поскольку искоренить из себя хрень крайне проблематично, то хотя бы погундосить о ней очень хочется. Итак, вот они, встречайте!
Проблема один - недооценка важности. Живя во времена, когда легковушки давно по своим размерам обогнали первые грузовики, мы привыкли к тому, что все самое важное и востребованное должно быть непомерно большим и дорогим. Особенно в IT. Это заблуждение. Порой софтина, разработка которой вышла в пару сотен тысяч рублей, за первые полгода может принести автоматизируемому бизнесу столько бабла, что окупит не только себя, но и параллельное внедрение какой-нибудь мегасистемы. Но самое нехорошее то, что при постановке задачи они (Заказчики) не имеют склонности нам (Разработчикам) говорить, как важен им продукт нашей деятельности, а сами мы эту важность узнаем только тогда, когда маленький победоносный проект завершен, внедрен и успел первый раз упасть на проде.
Проблема два - ошибка в понимании сложности решения. Если система маленькая, то это совсем не значит, что в основе ее будут простые архитектурные, алгоритмические или какие там еще решения. Иногда бывает совсем наоборот - трудоемкость создания продукта составляет дней 15, а решения, которые в него должны быть заложены, под силу только высококвалифицированному программисту. Самое обидное то, что осознание этой беды приходит уже во время еды. Причем порою до руководителя проекта приходит быстрее, чем до разработчика. Поэтому бойтесь специалистов, которые поглядев на бизнес-требования сходу обещают сделать решение в одно - два лица без привлечения аналитика с тестером за пару недель. Если такой парень появился, то почти наверняка очень скоро будет косяк. Ждите.
Проблема три - промахи в оценке / несоблюдение сроков. Что такое четыре человекодня для проекта трудоемкостью в двести? Правильно - пыль. А что такое четыре человекодня для проекта с трудоемкостью в 40? Согласитесь, есть разница. Поэтому, если команда в четыре человека (два девелопера, аналитик и тестер) промахивается на пару дней на проекте общей трудоемкостью 200 человекодней, то это вроде как в пределах погрешности. А на проекте трудоемкостью в 40 человекодней? За два дня команда в 4 человека теряет 8 человекодней, причем теряются они из чистой прибыли, которую вы хотели взять с проекта. Плюс вы теряете 8 невыработанных человекодней, поскольку ваша команда вместо нового проекта мусолит старый. Жесть!
Проблема четыре - привлечение слабых специалистов. Из личного опыта - почему-то бытует мнение, что на небольшой проект нет смысла привлекать сильных специалистов. Отчасти это вызвано с недооценкой важности и сложности ожидаемого решения. Но как бы то ни было, это досадное заблуждение. Как минимум два человека в команде должны быть синьоры. Это ведущий девелопер и аналитик. По этому пункту есть еще один нехороший вариант - когда свободных сильных ресурсов нет, возникает соблазн стартовать проект с тем, кто подвернулся. Понятное дело, что это от безысходности, но нужно в голове держать шанс вляпаться в первые две проблемы, на исправление которых попросту может не остаться ни средств, ни времени.
Проблема пять - заблуждение о возможности безболезненного изменения требований в ходе разработки. Казалось бы очевидная вещь - раз продукт маленький, то изменить в нем что-нибудь особого труда не составит. Но это опасное заблуждение. Как правило, архитектурные решения небольших приложений таковы, что внесение изменений в какие-то компоненты может быть более трудоемким, чем банальное переписывание кода. А это опять трудоемкость, опять потери (если только такие доработки не оплачивает Заказчик).
Описанные выше пять позиций - это те самые беды, с которыми мне в последнее время приходилось очень плотно сталкиваться и которые на вскидку пришли в голову. Т.е. наиболее наболевшие проблемы. Данный текст не претендует на полноту и является просто попыткой поделиться нажитым опытом, поэтому буду рад ответному потоку сознания :)
Проблема один - недооценка важности. Живя во времена, когда легковушки давно по своим размерам обогнали первые грузовики, мы привыкли к тому, что все самое важное и востребованное должно быть непомерно большим и дорогим. Особенно в IT. Это заблуждение. Порой софтина, разработка которой вышла в пару сотен тысяч рублей, за первые полгода может принести автоматизируемому бизнесу столько бабла, что окупит не только себя, но и параллельное внедрение какой-нибудь мегасистемы. Но самое нехорошее то, что при постановке задачи они (Заказчики) не имеют склонности нам (Разработчикам) говорить, как важен им продукт нашей деятельности, а сами мы эту важность узнаем только тогда, когда маленький победоносный проект завершен, внедрен и успел первый раз упасть на проде.
Проблема два - ошибка в понимании сложности решения. Если система маленькая, то это совсем не значит, что в основе ее будут простые архитектурные, алгоритмические или какие там еще решения. Иногда бывает совсем наоборот - трудоемкость создания продукта составляет дней 15, а решения, которые в него должны быть заложены, под силу только высококвалифицированному программисту. Самое обидное то, что осознание этой беды приходит уже во время еды. Причем порою до руководителя проекта приходит быстрее, чем до разработчика. Поэтому бойтесь специалистов, которые поглядев на бизнес-требования сходу обещают сделать решение в одно - два лица без привлечения аналитика с тестером за пару недель. Если такой парень появился, то почти наверняка очень скоро будет косяк. Ждите.
Проблема три - промахи в оценке / несоблюдение сроков. Что такое четыре человекодня для проекта трудоемкостью в двести? Правильно - пыль. А что такое четыре человекодня для проекта с трудоемкостью в 40? Согласитесь, есть разница. Поэтому, если команда в четыре человека (два девелопера, аналитик и тестер) промахивается на пару дней на проекте общей трудоемкостью 200 человекодней, то это вроде как в пределах погрешности. А на проекте трудоемкостью в 40 человекодней? За два дня команда в 4 человека теряет 8 человекодней, причем теряются они из чистой прибыли, которую вы хотели взять с проекта. Плюс вы теряете 8 невыработанных человекодней, поскольку ваша команда вместо нового проекта мусолит старый. Жесть!
Проблема четыре - привлечение слабых специалистов. Из личного опыта - почему-то бытует мнение, что на небольшой проект нет смысла привлекать сильных специалистов. Отчасти это вызвано с недооценкой важности и сложности ожидаемого решения. Но как бы то ни было, это досадное заблуждение. Как минимум два человека в команде должны быть синьоры. Это ведущий девелопер и аналитик. По этому пункту есть еще один нехороший вариант - когда свободных сильных ресурсов нет, возникает соблазн стартовать проект с тем, кто подвернулся. Понятное дело, что это от безысходности, но нужно в голове держать шанс вляпаться в первые две проблемы, на исправление которых попросту может не остаться ни средств, ни времени.
Проблема пять - заблуждение о возможности безболезненного изменения требований в ходе разработки. Казалось бы очевидная вещь - раз продукт маленький, то изменить в нем что-нибудь особого труда не составит. Но это опасное заблуждение. Как правило, архитектурные решения небольших приложений таковы, что внесение изменений в какие-то компоненты может быть более трудоемким, чем банальное переписывание кода. А это опять трудоемкость, опять потери (если только такие доработки не оплачивает Заказчик).
Описанные выше пять позиций - это те самые беды, с которыми мне в последнее время приходилось очень плотно сталкиваться и которые на вскидку пришли в голову. Т.е. наиболее наболевшие проблемы. Данный текст не претендует на полноту и является просто попыткой поделиться нажитым опытом, поэтому буду рад ответному потоку сознания :)
