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