11
30484
Каждому более-менее опытному аналитику приходится сталкиваться с такой активностью, как оценка трудозатрат на анализ в проекте. Активность эта сложная и ответственная, однако, избежать ее выполнения удается не часто, поэтому лучше научиться делать ее максимально хорошо.
В первую очередь, говоря об оценке, хочется сказать, что точных оценок не бывает – бывают более точные оценки и менее точные. А знать наверняка, сколько времени заняло выполнение той или иной задачи можно лишь постфактум. Но конечно надо стремиться к максимально точной оценке, с учетом выделенного времени и доступной информации. Далее
29 Июня, 2013
20 июня 2013 года интернет-платформа 
Пока среди аналитиков ведутся обсуждения, как оценить эффект от внедрения Средства Управления Требованиями (СУТ) – мы просто взяли систему и сделали на ней некое подобие пилотного проекта (как и все пионеры внедрения СУТ).
Какие целевые критерии успеха мы для себя определили? На самом деле довольно абстрактные, но позитивные. К сожалению, у нас не было накоплено никаких метрик, а по пилотному проекту их собирать особого смысла не было. В итоге мы будем ограничиваться только нашими ощущениями и голословными высказываниями. 
Как сказал однажды Наполеон, каждый солдат носит в своем ранце маршальский жезл (Tout soldat français porte dans sa giberne le bâton de maréchal de France). И уже давно не секрет, что в сфере IT каждый разработчик носит в своем бэге статус менеджера.
Но, как и в революционной Франции далеко не каждый солдат становился маршалом, так и не каждый программист в итоге становится руководителем или начинает свой стартап.
Как часто при общении с «бизнесом» или IT – представителями крупных компаний приходится слышать гордое высказывание: «Это наше уникальное ПО. Есть только у нас, и мы его постоянно развиваем и дорабатываем!»
Мне подобное приходится слышать крайне часто, потому что являюсь ИТ-аналитиком, специализирующимся на развитии заказного (коробочного) ПО.
В этой статье я не ставлю глобальных целей описания пути внедрения и развития такого ПО (некоторые процессы ЖЦ я всё-таки опишу), а просто хочу поделиться опытом, который, возможно, будет полезен и интересен. 
Мы живем в эпоху постоянных изменений, как мы слышим каждый день в новостях технологий и во время деловых встреч. Предприятия стараются идти в ногу с темпами изменений путем улучшения и трансформирования бизнеса. Все больше и больше инициатив и проектов должны быть завершены "вчера", что означает, что они имеют жесткие сроки и высокую актуальность. 
Все началось лет пять назад, когда я пришла работать офис-менеджером и помощником руководителя в одной из IT компаний. Тогда я была совсем юной девчонкой и совсем ничего не понимала в IT, разработке, анализе. 
Проработав аналитиком в ряде компаний, мне в той или иной степени приходилось тестировать то программное обеспечение, требования к которому я писал. Исключение составляет только одна компания, занимающаяся разработкой продуктовой линейки, но я и не утверждаю, что тестирование – задача для аналитика. Но, в самом худшем случае, ему приходится тестировать всё и вся самостоятельно, а в лучшем – на основании его тестов напишут тест кейсы и больше никогда не будут подходить с вопросами «а как оно должно работать?». 
