Я и технарь, и консалтер, и продажник. В каждой из этих профессий практиковал больше 10 тыс часов, поэтому этого не стыжусь. Сейчас выбрал писать не как технарь. Потому что пишу не для технарей.
Моя гипотеза заключается в том, что на хабре живут не одни технари (возможно потому, что я знаю кучу таких людей, читающих здесь посты?). Также хорошо знаю о колоссальной дистанции в языке, лежащей между «технарями» и «не технарями». И о том, что «технарский» язык последним непонятен, и неинтересен.
Я слово «учёт» здесь пишу с содроганием, потому что аудитория, для которой пишу, думает что это то ли счёты, то ли чётки. Попробуйте написать технический пост для детского сада, потом обсудим этот увлекательный опыт =)
Честно говоря, познакомившись с основателем, я впервые вживую увидел миссию, которая работала — а не была просто громким лозунгом. Был удивлен. Ну и понятно, чтобы это реализовать — у них просто адски были проработаны логистические и складские процессы.
Относимся ко всем уважительно. Мы выделяем 5 типов наших клиентов, и подобная ситуация чаще всего может возникнуть у типа «стартаперы-любители».
В зависимости от запущенности ситуации можем сказать от «скорее всего ваша задача будет бесполезна, потому что...» до «ребята, чтобы вы не потеряли деньги — рекомендуем вам поучиться/почитать… на тему создания ИТ стартапов». Дальше есть варианты. С кем-то не будем работать даже если будет просить, а кому-то выполним разработку.
Пример. Приходят ребята, их основной бизнес — фермеры, занимаются консервацией овощей. Хотят заказать Авито с платежами криптовалютами. Считают, что ничего подобного на рынке нет. И что сам факт существования продукта обеспечит успех. Ну и конечно, что надо просто сделать копию Авито. Угадаете, что мы им скажем?
Я же говорю о том, как есть в реальных компаниях — исходя из своего опыта построения и анализа управленческого учета в компаниях, занимающихся заказной разработкой ПО (так получилось, что некоторое их количество обращалось ко мне за советом).
Это очень легко проверить. Напишу статью, дам несколько проверочных вопросов — спросите друга-руководителя ИТ компании и узнаете, насколько я прав или нет.
Когда-нибудь я обязательно дойду до статьи «управленческий учет, финмодель, ценообразование в заказной разработке». Вам понравится.
Краткий пересказ: в большинстве айтишных компаний (больше 10 сотрудников)
1. ценообразование не имеет никакой связи с затратами и прибылью.
2. цель ценообразования — либо показать клиенту, что мы тут все считаем, либо продать.
3. заработает ли исполнитель на проекте и сколько — он не знает.
Извините, если скажу глупость, но мнение со стороны обывателя.
Спасибо за ваш отклик. Именно с такими мнениями мы и сталкиваемся, и пытаемся найти общий язык. Для нас это тоже выглядит, как разговор с другой вселенной =)
И хочу услышать простой ответ, который даст мне общее представление о порядке суммы.
Бывают ситуации, где простой ответ все только усложняет. Пример: семья, муж с женой регулярно ссорятся, есть маленькие дети. Муж приходит к специалисту и спрашивает — жена не дает, как ходить налево, чтобы ей стало стыдно?
Добраться из пункта а в пункт б. А там под капотом хоть карлики педали крутить будут.
В том-то и проблема, что клиенты не говорят про задачу из пункта А в пункт Б. А говорят про карликов. Вам все равно, будут ли карлики крутить педали или нет. А мы сразу видим, что через год для карликов надо будет найти карлиц (иначе они откажутся работать), через два — вендиспансер, а через три — заменить карликов на китайцев. Понимаем, что вы этого не видите и, возможно, вам не очень понравятся такие последствия. Поэтому идем в глубину и начинаем вас «грузить». Уж простите за это.
Вы же когда приходите к стоматологу спрашиваете " у меня болит зуб, сколько будет вылечить" а не описываете полный план всего курса лечения.
Когда вы приходите к специалисту исправить прикус, вы врядли ожидаете, чтобы вам сделали 5 часовую операцию, где отпилят кусок челюсти. Но именно таким был тип прикуса Васи, когда вы попросили общий функционал «сделайте мне зубы, как Васе». Именно поэтому вам и рассказывают план лечения.
И вот, когда я ожидал, что будет предложено одно из двух решений
1) включить подробный бизнес-анализ в структуру проекта
2) работать в лучших традициях agile
Про бизнес-анализ — я знаю от силы человека 2 в России, которые могут сделать не просто бумажку, а что-то полезное. В моей компании таких людей нет (мы все-таки разработчики). Если бы были, врядли бы они занимались написанием бизнес-анализов за деньги :)
Касательно agile — в общем случае клиент хочет ограничивать сроки и затраты. И ему кажется, что agile такой возможности не дает. Мы не хотим идти против рынка.
Почему все равно ТЗ? Нам надо как-то разойтись с клиентом. Показать ему, что он получил именно то, что запрашивал. Поэтому даже если пойдем в гибкую разработку — все равно напишем верхнеуровневую постановку задачи. Разумеется, писать ТЗ на FB не будем.
Хотел сказать, что нам не просто недоступна начинка системы, но и часть функций тоже — например, кто нас пустит в админку — но получилось двусмысленно =)
Моя гипотеза заключается в том, что на хабре живут не одни технари (возможно потому, что я знаю кучу таких людей, читающих здесь посты?). Также хорошо знаю о колоссальной дистанции в языке, лежащей между «технарями» и «не технарями». И о том, что «технарский» язык последним непонятен, и неинтересен.
Я слово «учёт» здесь пишу с содроганием, потому что аудитория, для которой пишу, думает что это то ли счёты, то ли чётки. Попробуйте написать технический пост для детского сада, потом обсудим этот увлекательный опыт =)
P.S. ссылку вырежем
Честно говоря, познакомившись с основателем, я впервые вживую увидел миссию, которая работала — а не была просто громким лозунгом. Был удивлен. Ну и понятно, чтобы это реализовать — у них просто адски были проработаны логистические и складские процессы.
В зависимости от запущенности ситуации можем сказать от «скорее всего ваша задача будет бесполезна, потому что...» до «ребята, чтобы вы не потеряли деньги — рекомендуем вам поучиться/почитать… на тему создания ИТ стартапов». Дальше есть варианты. С кем-то не будем работать даже если будет просить, а кому-то выполним разработку.
Пример. Приходят ребята, их основной бизнес — фермеры, занимаются консервацией овощей. Хотят заказать Авито с платежами криптовалютами. Считают, что ничего подобного на рынке нет. И что сам факт существования продукта обеспечит успех. Ну и конечно, что надо просто сделать копию Авито. Угадаете, что мы им скажем?
Я же говорю о том, как есть в реальных компаниях — исходя из своего опыта построения и анализа управленческого учета в компаниях, занимающихся заказной разработкой ПО (так получилось, что некоторое их количество обращалось ко мне за советом).
Это очень легко проверить. Напишу статью, дам несколько проверочных вопросов — спросите друга-руководителя ИТ компании и узнаете, насколько я прав или нет.
Краткий пересказ: в большинстве айтишных компаний (больше 10 сотрудников)
1. ценообразование не имеет никакой связи с затратами и прибылью.
2. цель ценообразования — либо показать клиенту, что мы тут все считаем, либо продать.
3. заработает ли исполнитель на проекте и сколько — он не знает.
Спасибо за ваш отклик. Именно с такими мнениями мы и сталкиваемся, и пытаемся найти общий язык. Для нас это тоже выглядит, как разговор с другой вселенной =)
Бывают ситуации, где простой ответ все только усложняет. Пример: семья, муж с женой регулярно ссорятся, есть маленькие дети. Муж приходит к специалисту и спрашивает — жена не дает, как ходить налево, чтобы ей стало стыдно?
В том-то и проблема, что клиенты не говорят про задачу из пункта А в пункт Б. А говорят про карликов. Вам все равно, будут ли карлики крутить педали или нет. А мы сразу видим, что через год для карликов надо будет найти карлиц (иначе они откажутся работать), через два — вендиспансер, а через три — заменить карликов на китайцев. Понимаем, что вы этого не видите и, возможно, вам не очень понравятся такие последствия. Поэтому идем в глубину и начинаем вас «грузить». Уж простите за это.
Когда вы приходите к специалисту исправить прикус, вы врядли ожидаете, чтобы вам сделали 5 часовую операцию, где отпилят кусок челюсти. Но именно таким был тип прикуса Васи, когда вы попросили общий функционал «сделайте мне зубы, как Васе». Именно поэтому вам и рассказывают план лечения.
Про бизнес-анализ — я знаю от силы человека 2 в России, которые могут сделать не просто бумажку, а что-то полезное. В моей компании таких людей нет (мы все-таки разработчики). Если бы были, врядли бы они занимались написанием бизнес-анализов за деньги :)
Касательно agile — в общем случае клиент хочет ограничивать сроки и затраты. И ему кажется, что agile такой возможности не дает. Мы не хотим идти против рынка.
Почему все равно ТЗ? Нам надо как-то разойтись с клиентом. Показать ему, что он получил именно то, что запрашивал. Поэтому даже если пойдем в гибкую разработку — все равно напишем верхнеуровневую постановку задачи. Разумеется, писать ТЗ на FB не будем.
Хотел сказать, что нам не просто недоступна начинка системы, но и часть функций тоже — например, кто нас пустит в админку — но получилось двусмысленно =)
Вы правы — большинство таких не хотят разбираться, как все устроено.
Но их, честно, по-человечески жалко — т.к. они просто потеряют деньги, время, нервы, когда встретят человека «вай, конечно сделаем, что за вопрос!».
Способ, которым мы ладим с этим — обучать клиента. В частности, такими статьями.