Комментарии 34
По поводу задачи — предположений здесь придётся сделать даже больше, чем в настоящем продакшене, потому что даже непонятно, о каком приложении идёт речь. Это может быть огромная банковская система или обычная игра, в которой есть банк (кстати, второй вариант мне кажется более вероятным — не думаю, что в настоящих банковских системах есть интерфейс Bank :) ). Это может изменить оценку времени на 1-2 порядка.
Так что ответ банальный — мне нужно n времени и m денег, чтобы определить, сколько времени на это уйдёт.
Так что ответ банальный — мне нужно n времени и m денег, чтобы определить, сколько времени на это уйдёт.
Статья какая-то неоконченная и поэтому бесполезная получилась.
Я недавно понял, что оценить сроки программного проекта получается плохо, потому что программирование — это фрактал. Издалека путь реализации кажется прямым. Но по мере приближения становятся видны всякие изгибы, и в результате длина пути оказывается больше в несколько раз.
Основная проблема современной разработки, а точнее особенность рынка СНГ состоит в том, что разработчикам приходится делать много Предположений, что само по себе плохо, т.к. жизнь показывает — в подавляющем большинстве случаев Предположение оказывается неверным. Для того, чтобы от той проблемы избавиться, необходимо тратить достаточно большое время на предпроектное исследование, а это несет за собой большие риски как для Клиента, так и для Разработчика. Ни одна из сторон не готова брать на себя эти риски и связанные с ними. Потому зачастую мы имеем как результат проект, который не попадает ни в сроки, ни в бюджет, ни в ожидания заказчика/пользователей. Это лично мое мнение.
В качестве отступления хотел бы помечтать и отправиться в то время, когда будут существовать компании, предоставляющие услуги предпроектного исследования для заказчиков ИТ сферы. Тогда бы количество успешных проектов могло бы вырасти хотя бы раза в 2 )) что уже очень немало.
В качестве отступления хотел бы помечтать и отправиться в то время, когда будут существовать компании, предоставляющие услуги предпроектного исследования для заказчиков ИТ сферы. Тогда бы количество успешных проектов могло бы вырасти хотя бы раза в 2 )) что уже очень немало.
а точнее особенность рынка СНГ
А разве вне СНГ по-другому? Мне кажется, эта проблема относится ко всей индустрии.
компании, предоставляющие услуги предпроектного исследования для заказчиков ИТ сферы
Будем ждать. Сейчас, видимо условия рынка не те. Идея ведь очевидная; если бы это было прибыльно, подобных компаний было бы полно.
А разве вне СНГ по-другому? Мне кажется, эта проблема относится ко всей индустрии.
Там причины другие. У нас например не уделяют должного внимания по причине того, что это стоит денег, а Заказчик всегда хочет дешевле, даже ценой качества и жизнеспособности продукта. На западе скорее причиной опускания основательного исследования будет то, что сам продукт будет громоздким и для его полноценного исследования понадобится слишком много времени, что в результате сорвет планируемый тайм2маркет и решение просто перестанет быть конкурентным. Но это скорее мое предположение, статистики, на которую я бы мог ссылаться в ходе рассуждений у меня нету (
если бы это было прибыльно, подобных компаний было бы полно.
Вопрос не в прибыльности, а в том, что спроса нету. Точнее потребитель еще не осознает, что такой сервис ему нужен и позволяет экономить бюджет, а не высасывает его впустую.
Я не думаю, что предпроектное обследование отдельной фирмой жизнеспособно, так как непонятно, кто и как будет оценивать результат такого обследования. И как этот результат будет передаваться испольнителю. По крайней мере для обычного бизнеса, не для атомных электростанций.
Результатом любого предпроектного исследования становится документ — техническое задание. Во всяком случае в моей идеальной вселенной. С детальным ТЗ, которое однозначно описывает моменты, критические для бизнеса, можно смело направляться к исполнителям с вопросом о сроках и стоимости.
В моей, неидеальной вселенной, документы сами по себе работают дороже и глючнее, чем доступ к мозгу того, кто этот документ сформировал. Результатом предпроектного обследование является также изменение состояния нейронов обследующего. Часть этого изменения попадает в документ, часть — нет. Если есть доступ к этому мозгу, документ может быть хорошим подспорьем, если нет, часто делается не то.
Согласен. Кейс абсолютно реальный. Но ничто, например, не мешает в рамках услуг бизнес анализа/предпроектного исследования предоставлять также и последующее ведение проекта с выбранным Исполнителем проекта. Но, в моем опыте есть случаи, когда заказчик приходил с настолько детальным ТЗ, что необходимости в доступе к «мозгу» не было. Садись, оценивай время, бей на задачи и работай. Такое тоже бывает.
В моей идеальной вселенной результатом ППО/ППИ является отчет. А ТЗ делается уже затем.
IMHO инженеров толковых у нас много, а хороших руководителей продуктов (проектов) мало; система образования так построена была с советских времен, чтобы догнать и перегнать любой ценой. Не уверен, что стало лучше. А где черпать хороших управленцев для сложных разработок без соответствующего образования?
Т.е. нельзя сказать, что их совсем нет; их мало, и все в Яндексе (братцы, это шутка, конечно;-)
Т.е. нельзя сказать, что их совсем нет; их мало, и все в Яндексе (братцы, это шутка, конечно;-)
Ну, должен сказать, что для ИТ отрасли современная система образования не готова. Сужу, как выпускник Киевского Политехнического. Хороших управленцев можно подготовить из современных разработчиков. Я, например, работал около 3 лет разработчиком. В рамках собственного опыта часто становился тимлидом. На предпоследнем месте работы, а это была средняя аутсорсинговая компания, понял, что самой частой проблемой в жизни наших проектов был именно плохой менеджмент. Сейчас я нарабатываю опыт как ПМ. С уверенностью могу сказать, что ели у вас в штате сотрудников есть лиды или старшие разработчики, или даже мидлы, у которых коммуникативные навыки на высоком уровне, попробуйте дать им литературу по менеджменту проектов, попробуйте дать им возможность пообщаться с клиентом напрямую, возможно у вас под носом сидит ваш следующий толковый ПМ, а может быть даже и КоммДир ;)
вот я об этом и говорю, что вместо фундаментального управленческого образования наша индустрия (слишком часто) питается самообразованием наиболее успешных технарей… и слишком часто перемешивает две роли.
Разработка продукта — это всегда торг: столько-то и за столько-то. И всегда компромисс: это делаем сейчас, это потом, а вот это — никогда. Ответ на эти вопросы знает только руководитель продукта ("продакт"), управленец по складу ума с техническим бэкграундом, а не технарь с управленческими навыками. Да, оценка трудоёмкости — определённо задача инженерной вертикали (лидов, мидлов, диров), так что по теме данной публикации авторитетным будет именно их мнение. Но проектирование продукта и увязка желаемого с достижимым — это задача продакта. Пословица бродит: какой продакт, такой и продукт.
В привычной мне вселенной технари развиваются в технических руководителей, но «продакты» — это другое (высшее) сословие. Да, между Инженерией и Продактами идёт постоянный диалог, но это два *разных* состояния ума. Вот только что посмотрел профиль одного своего продакта, так он был продактом всю свою карьеру… И именно этого состояния без специального образования достичь очень сложно.
Вам, коллега, я искренне желаю преуспеть в Вашем начинании, но позвольте провести черту между хорошим руководителем технарей и хорошим руководителем продукта: почувствуйте разницу и сделайте правильный выбор. См. также Agile, SCRUM и т.д.
Разработка продукта — это всегда торг: столько-то и за столько-то. И всегда компромисс: это делаем сейчас, это потом, а вот это — никогда. Ответ на эти вопросы знает только руководитель продукта ("продакт"), управленец по складу ума с техническим бэкграундом, а не технарь с управленческими навыками. Да, оценка трудоёмкости — определённо задача инженерной вертикали (лидов, мидлов, диров), так что по теме данной публикации авторитетным будет именно их мнение. Но проектирование продукта и увязка желаемого с достижимым — это задача продакта. Пословица бродит: какой продакт, такой и продукт.
В привычной мне вселенной технари развиваются в технических руководителей, но «продакты» — это другое (высшее) сословие. Да, между Инженерией и Продактами идёт постоянный диалог, но это два *разных* состояния ума. Вот только что посмотрел профиль одного своего продакта, так он был продактом всю свою карьеру… И именно этого состояния без специального образования достичь очень сложно.
Вам, коллега, я искренне желаю преуспеть в Вашем начинании, но позвольте провести черту между хорошим руководителем технарей и хорошим руководителем продукта: почувствуйте разницу и сделайте правильный выбор. См. также Agile, SCRUM и т.д.
На мой взгляд и Вы и bershadskiy неправы в том, что пиняете именно на наших управленцев. Я работал в 2 крупных Российских компаниях, а также с 4-я зарубежными заказчиками, среди которых было два «типа стартап» и две крупные фирмы. Так вот, мой опыт говорит о том, что разницы в управлении просто нет. Ни в общих принципах, ни в частностях. На мой взгляд, проблема управления не является бичом пост-советской системы, это обдщемировая проблема, общего решения которой найти вряд-ли возможно, т.к. управление людьми процесс не детерменированный и в рамки математической модели его загнать вряд ли возможно.
сужу с точки зрения производства программных продуктов; безусловно, хорошие продакты везде в дефиците, но если сравнивать Силиконовую долину и СНГ, согласитесь, концентрация явно не в пользу второго…
кстати, толковых ребят, у которых русский язык был родным, встречаю в инженерных вертикалях часто; правда, не менее часто еще один родной у них иврит :)
кстати, толковых ребят, у которых русский язык был родным, встречаю в инженерных вертикалях часто; правда, не менее часто еще один родной у них иврит :)
Кремниевая долина это вообще уникальный феномен, такое больше не получилось сделать ни у одной страны. К этому могло привести множество факторов. К примеру: большая масса денег сосредоточенных и привлекаемых в США, дух предпринимательства(готовность рисковать) и много всего прочего. Фактор качества управленческих кадров, безусловно, сыграл свою роль, но это не занчит, что там все управленцы хорошие, а у нас плохие. Или что там лучше школа воспитания управленцев. Там, вероятно, хороших больше, в силу хотя бы того, что в Кремниевыую долину попасть хотят очень многие, в том числе и из России.
Вообще, анализ таких феноменов как Кремниевая долина, на мой взгляд, не очень продуктивен. Насколько я знаю, никто так до сих пор и не определил чем была вызвана Эпоха Возрождения, Серебренный Век в России и т.п. Точнее идей выдвигается вагон, но если бы кто-то мог понять истинную причину, то можно было бы повторить успех, но, что-то, видимо, не вяжется.
Вообще, анализ таких феноменов как Кремниевая долина, на мой взгляд, не очень продуктивен. Насколько я знаю, никто так до сих пор и не определил чем была вызвана Эпоха Возрождения, Серебренный Век в России и т.п. Точнее идей выдвигается вагон, но если бы кто-то мог понять истинную причину, то можно было бы повторить успех, но, что-то, видимо, не вяжется.
Коренная проблема в оценке сроков в том, что это пытаются сделать как некое пассивное предсказание, а нужно занимать активную позицию. Для удачной оценки нужно а) Определить приемлимый способ решения задачи, и понять какой срок приемлимый с точки зрения бизнеса. Тут что-то вроде торга, типа я могу сделать A за X или B за Y. б) Нужно стараться успеть попасть в этот срок, на ходу расставляя приоритеты и корректируя план работ на ходу. Понятное дело, что с чем-то будут проблемы, но важно всегда понимать насколько проблемная часть важна с точки зрения бизнеса. Возня с низкоприоритетными задачами — главная причина срыва сроков.
Главная проблема в том, что те, кто пытается делать оценки сроков, в большинстве случаев даже не слышали о метрологии и стандартизации, а также о процессах. Да, все эти ISO 9000, ISO 9001, MSF, Agile, Scrum, TQM и так далее — не являются «серебряной пулей», но они действительно полезны там, где нужны (понятно, что для школьника, пишущего сайты-визитки, не нужно получать 5 уровень CMMI. Это всё инструменты, которыми надо уметь пользоваться).
Согласен, но я бы скорее обобщил до такого: оценка вообще является довольно сложной дисциплиной, для овладения которой нужна мотивация. Всякие методологии конечно помогают, так как они создают некоторый набор ограничений, от которых можно отталкиваться. Но проще ведь сидеть просто писать код, и доказывать всем (порой весьма успешно), что задачу невозможно оценить и так далее :)
сколько времени понадобится, чтобы реализовать новую деталь, связанную с вкладами
Может быть лучше перевести «чтобы реализовать новые функции» или «новую фичу».
И, кстати, о сути. Почему размещение депозитов сразу не сделали?
Сколько времени вам понадобится?
А какая точность оценки вас интересует?
Основная проблема оценки в том, что её рассматривают с точки зрения разработки, а не бизнеса.
Нужно не задаваться вопросом сколько это займёт, а к какому числу нужно реализовать, а дальше уже подстраиваться под сроки, добавлять, резать фичи, использовать коробочные решения, наплевав на производительность и прочие костыли. И хотя я говорю о костылях, на практике, при таком подходе обычно появляется свободное время для рефакторинга и постоения нормальной архитектуры.
Нужно не задаваться вопросом сколько это займёт, а к какому числу нужно реализовать, а дальше уже подстраиваться под сроки, добавлять, резать фичи, использовать коробочные решения, наплевав на производительность и прочие костыли. И хотя я говорю о костылях, на практике, при таком подходе обычно появляется свободное время для рефакторинга и постоения нормальной архитектуры.
Лично я постоянно встречаю людей, которые очень точно могут определять срок выполнения задач, так что проблема надуманная. Любимая фраза этих людей: «Тут же делов на 5 минут».
А еще забывают, что эта оценка, на самом деле, вероятностная. Взять тот же авиаперелет: 70% прилетает за два часа, 95% — за восемь часов, 99,99% прилетают за двое суток (цифры с потолка).
И тут опять вспоминается джоэл
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Почему так сложно оценивать сроки разработки (плюс задача для разработчиков)