Более года назад я опубликовал пост про экономику проектов. Ко мне обращались читатели с просьбой помочь в оценке, и со временем я понял, что тот пост не очень хороший. Поэтому предлагаю ознакомиться с более детальным подходом.
Под катом будут финансовые методы, опробованные на ИТ-проектах, в частности — как составить дорожную карту, как работать с горизонтом планирования, как подсчитать показатели, как проанализировать риски.
Проработав несколько лет в небольших web агентствах, 5 месяцeв назад я решил попробовать что-то новое и устроился в довольно крупную (3500 сотрудников) IT-компанию. То, что я увидел на новом рабочем месте, оказалось очень далеким от моих ожиданий. По многочисленным просьбам моих друзей и в ответ недавней статье под катом несколько наблюдений о различиях между большими и маленькими IT компаниями. На вкус и цвет, как известно, фломастеры разные. Так что эта статья — далеко не истина в последней инстанции, это то, с чем я столкнулся и что было для меня важным.
Люди забавно реагируют на предложения в интернете: часто верят тому, чему верить глупо и даже опасно, и не верят тому, чему нет явных причин не доверять. Нижеследующий текст — не результат исследования этого явления, а скорее обобщение опыта в надежде на его расширение в комментариях.
Доверие — это большой дефицит в современном мире, уверен, что вы согласитесь с тем, что его приобретение и сохранение важно и в IT, и в бизнесе вообще, и в завоевании желанного сердца.
Случалось ли вам встречать недоверие и нелогичные — казалось бы — отказы со стороны клиентов? Мне – да, и ниже я расскажу, почему они возникают, и как я с этим пытаюсь бороться. Будет замечательно, если вы в комментариях расскажете о своих методах борьбы. Подчеркну: сейчас мы говорим о предложении тех услуг, которые на самом деле необходимы клиенту, а если вы умеете бороться с возражениями, продавая купоны МММ, ваш опыт здесь не совсем применим (хотя в жизни он, может быть, вдвое полезнее).
Моя статья будет представлять собой больше набор историй из жизни и некоторые выводы из них. Основная проблема, которая меня сейчас волнует: как сделать так, чтобы довольны были и заказчики, и разработчики, и прибыль была и карма цела. Конкретного окончательного рецепта у меня нет, есть несколько отрицательных примеров и намеченные цели, которыми хочется поделиться.
Я занимаюсь разработкой с 2003 года (в основном web-приложения), до этого 4 года преподавала в ОмГУ основы программирования для 1-го курса математического факультета. На данный момент у меня пошел 3-й год в роли совладельца собственной небольшой аутсорсинговой компании (http://7bits.it). Рассказывать буду исключительно о своем опыте по двум причинам: я успела побывать в трех различных типах компаний, которые могу сравнить, и считаю, что пересказ чьего-то опыта не дает полной картины.
Читать полностью »
Disclaimer: Я в курсе что «индусский код» это очень сильный негативный брэнд среди разработчиков в России и у большинства в голове масса предрассудков на эту тему. Очень не хотелось бы получить шовинистский срач в комментариях хотя я почти уверен, что этого не избежать. Также я почти уверен что мои индийские коллеги этот пост прочитают хотя бы в переводе. Поэтому давайте постараемся выглядеть цивилизованными профессионалами в вопросах и комментариях.
Моя профессиональная карьера сложилась таким образом, что в настоящий момент я работаю техническим директором в компании Knoema и в моем подчинении оказалась очень необычная команда состоящая из российских (Пермь) и индийских (Bangalore) разработчиков. За почти 2 года такой работы накопилось много полезных наблюдений. Да и вообще тема достаточно интересная поскольку практически все мои знакомые из ИТ интересуются как оно там в Индии и чем русские разработчики отличаются от индийских. До этого я более 10 лет работал в разработке ПО в России и США, из них более 7 лет руководителем разных рангов. Вот я и решил поделиться накопившимся «интернациональным» опытом.
Читать полностью »
Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.Читать полностью »
В 2006 я плотно занимался IT-инфраструктурой школ города. Однажды ко мне пришел человек и сказал примерно следующее: «Я — отец девочки-инвалида. Насколько я знаю, школы все подключены в одну сеть. А нельзя как-то организовать обучение так, чтобы дети учились через компьютер и сеть?» И в этот момент я вдруг понял, что сделать это можно и я примерно представляю как именно.
О том, что вышло, какие были успехи и трудности — под катом.
За время своей работы мне удалось взглянуть на процесс разработки технических заданий на программные продукты с нескольких точек зрения. С точки зрения аналитика – непосредственного исполнителя работ, с точки зрения руководителя проекта со стороны исполнителя, организующего процесс создания ТЗ, с точки зрения руководителя группы разработчиков, реализующих эти самые ТЗ, а также с точки зрения заказчика системы, впоследствии принимающего решение по разработанному ранее ТЗ.
Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. Конечно же, при другом «менталитете» заказчика и исполнителя все может быть с точностью до наоборот. Сейчас мне хотелось бы остановиться именно на разработке ТЗ с точки зрения его заказчика, рассмотрев возможные ситуации, цели и тактики поведения.
Читать полностью »
На сегодняшний момент известно огромное множество разных программных решений для управления проектами любого типа, в любом масштабе, с любыми ограничениями. Я думаю, не имеет смысла перечислять их всех, сосредоточимся лишь на их координальных отличиях.
В общем, их можно разделить на две основных группы: desktop-приложения, использующиеся в основном крупными компаниями с большим документооборотом и сложной схемой подчинения и иерархии, и web-based приложения, более дружелюбные, доступные и потому лучше подходящие малым/среднемалым бизнесам, а иногда и вовсе использующиеся для домашних нужд.
Отдельно я бы хотел рассказать об одном веб-приложении от российских разработчиков, основанном на связке PHP/MySQL и wiki-движка, которое наша команда держит на вооружении уже второй год. Речь идет о проекте под названием qdPM — бесплатном инструменте управления проектами с открытым кодом, отлично подходящих для небольших компаний, в особенности в сфере IT и интернет-маркетинга. qdPM полностью конфигурируем, имеет возможность настройки различных уровней доступа, а также множество подключаемых модулей и расширений.
Мощный генератор отчетов, гибкая настройка, удобство планирования — все это поможет Вам и Вашей команде сэкономить время и сделать ведение и управление проектами простым и удобным.
— именно такое описание встречает посетителей официального сайта проекта. Читать полностью »
Лето 2012… Проект nanoCAD, разрабатываемый нашей компанией претерпел существенные изменения: из бесплатного nanoCAD выделилась платная версия. Можно сказать, что мы прошли первую ступень Star(T)Up’а – nanoCAD крепнет и развивается. Далее путешествие по бескрайним просторам САПР-космоса будут осуществлять две (одинаково важные для нас) версии nanoCAD.
О причинах разделения, различиях и наших планах на будущее – в статье ниже.
Читать полностью »
