Основной миф на эту тему - само понятие "искусственный интеллект". Чтобы это понять, достаточно прочитать, что такое интеллект: "Интелле́кт или ум — качество психики, состоящее из способности осознавать новые ситуации, способности к обучению и запоминанию на основе опыта, пониманию и применению абстрактных концепций, и использованию своих знаний для управления окружающей человека средой".
В этом определении главное, что интеллект - это свойство психики! После этого можно закрывать все рассуждения об искусственном интеллекте. Но еще одно свойство интеллекта, которое отличает его например от разумного поведения животных. Это - управление окружающей средой. Именно управление, т.е. анализ ее и изменение под свои потребности. Естественно, что у нынешних программ, которые отнесены к этом виду ПО, нет своих потребностей и они не изменяют окружающую среду.
Таким образом, скажем так, компьютерного интеллекта не существует и в ближайшей перспективе не предвидится. Но, как программный продукт, т.е. товар, "искусственный интеллект" существует и продается очень даже хорошо благодаря агрессивной рекламе. А почему бы и нет.
М-да! Что называется приехали. Времена меняются и с этим ничего не поделаешь. А можно ли при таком целеполагании достичь главного - счастья?
Все же по старинке рекомендую цели: построить дом, посадить дерево и вырастить сына.
Это древняя мудрость, вернее ее интерпретация, но это не важно. Конечно, "дом" - это не особнячок в 4 - 10 - 20... стен. Дом - это место, где будет расти твое дерево и твое дитя.
Это же и алгоритм действий. Или как пишет автор "фильтр".
Только достижение этих целей приводит к счастью. Вот этого всем и желаю.
Ставьте правильные цели и тогда не придется писать "я засел один в пустой квартире" .
Ну, так включите. И тогда Вы поймете, что написали не о рисках, а о каких-то текущих проблемах. Отличие: риск - это события во внешней среде (обычно), на которую Вы можете оказать небольшое влияние. А проблемы - это события в Вашей обстановке, которую Вы сами формируете. Риски надо обходить, а проблемы - решать и желательно до начала проекта.
И не надо "упрощать реестр рисков" - попробуйте их не придумывать.
Я старый разработчик и все эти рассуждения для меня настолько банальны, что задаюсь вопросом: неужели всё так деградировало, что эти банальности обсуждаются в статьях, блогах и т.д. Я бы постеснялся выкладывать на свет божий свою некомпетентность.
Ребята, а не пробовали уяснить такие понятия, как "проект", "управление проектом"? Не пробовали писать техническую документацию? Или вера не позволяет? Я имею в виду эджайл.
У Вас нет формулировки понятия "риск". Все, что вы включили в перечень "рисков" к рискам никакого отношения не имеет. Это обычные технические и организационные проблемы. Впрочем, их даже проблемами назвать трудно, так как они связаны с плохим управлением проектом или даже просто с разгильдяйством сотрудников и, в первую очередь, руководителя проекта (РП).
В Вашем случае риск один - РП не хватает квалификации.
С большинством Ваших рассуждений согласен, но Вы повторяете принципиальную ошибку многих авторов, пишущих на эту тему – ошибка в назначении ТЗ. Вы пишите:
Кому будет полезна статья: представителям заказчиков …; тендерным специалистам со стороны как заказчика …; заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).
И при этом забываете, что сущность ТЗ заключается в самом названии этого документа –задание кому? Заказчику? Абсурд! ТЗ на АС – это задание программистам, в широком понимании. Т.е. это задание ИТ-специалистам, которые непосредственно будут выполнять разработку системы. ТЗ – это настольная книга для программиста, и прежде чем что-то накодить, он должен посмотреть в ТЗ.
Соответственно этому и писать ТЗ надо, как задание программисту. Тогда становится ясно, что из всей проектной документации ТЗ присутствует ВСЕГДА! Печати и подписи начальников не всегда обязательны, но нормальный программист ВСЕГДА хоть на полстраницы, сделает его для себя, прежде чем что-то закодировать.
А ГОСТ 34 до сих пор живой, потому что в нем заложен универсальный алгоритм мышления человека. Что бы вы не делали, хоть табуретку, хоть полет на Марс, вы будете мыслить по этому алгоритму. Все прочие методологии используют этот же алгоритм и отличаются в мелочах.
Вот только системным и логическим мышлением не каждый специалист обладает. Плюс лень-матушка: как не хочется тратить свое драгоценное время на писанину. Да и литературные способности не помешали бы. Поэтому за четверть века своей работы я видел единицы хороших ТЗ. Приходится самому писать или переписывать. Но оно того стоит!
На ваш взгляд, нужно ли получать профильное образование (высшее, среднее специальное), чтобы влиться в сферу IT?
Коллеги, о чем спор? Пусть простят меня авторы этого вопроса, но им явно не хватает образования! Во-первых, что такое «влиться в сферу IT»? Если сотрудник разгружает коробки с IT-техникой у клиента, это считается, что он «влился»? А водитель, который привез эту технику, «влился»? А тот же сотрудник воткнул вилку принтера в розетку и установил драйвер? А официант на своем мобильнике принял заказ и оплату, он «влился в сферу IT». И т.д. Во-вторых, и это главное. Далеко ходить не будем, а посмотрим в Википедии, что такое «образование»: «Образова́ние — система воспитания и обучения личности, а также совокупность приобретаемых знаний, умений, навыков, ценностных установок, функций, опыта деятельности и компетенций. В широком смысле слова, образование — процесс или продукт формирования ума, характера и физических способностей личности.»
Ключевое здесь — это «воспитание и обучение личности» и прочее можно назвать кругозором. Формировать личность можно только при общении Учителя с учеником и только очно, хотя бы на первом этапе. По любому разделу обучения есть десятки, может быть, тысячи учебников и авторитетов, а Учитель десятикратно сокращает пустую работу поиска нужного и полезного, предлагая свой метод, знания, навыки… Раньше это называлось научной школой.
Можно ли это все получить самостоятельно? Можно, и это очевидно и не требует доказательств, но эффективность такого обучения (соотношение времени обучения к времени поиска и освоения нужного из моря информации) — чуть выше нуля. С Учителем — приближается к единице, но остальное — самостоятельная работа!
Тот, кто УЧИЛСЯ в универе, тот помнит, сколько «ненужного» приходилось учить! Казалось зачем? И только получив свой опыт, начинает доходить для чего это надо было. Если что-то пропустил по молодости и глупости, изучаешь самостоятельно. И здесь самое главное, что образование позволяет самостоятельно определить, что еще тебе надо и с какой глубиной. Ну, и последнее, это в-третьих. Самостоятельно можно научиться кодить что-нибудь. А, если надо прочитать технический проект, или даже техзадание? Т.е. надо понять, как твой кусок программы влияет на результат работы всей системы?
А если ты проектируешь многопрофильную систему? Необходимо знание процессного управления. А здесь без широкого кругозора не обойтись, т.к. на входе один продукт и поставщики, на выходе другой продукт и потребитель, между ними процесс. Все компоненты процесса надо не только знать, но и понимать их природу. Можно научиться делать обследование самостоятельно? Думаю можно за несколько лет набивания шишек, которые на практике выражаются в штрафных санкциях и судебных издержках.
Поэтому проблема, как учиться в ВУЗе или самостоятельно — это надуманная проблема. Без университета быстро стать высококлассным специалистом трудно, еще труднее стать руководителем высшего уровня. Но самостоятельное обучение — это стезя любого классного специалиста до самого гроба!
Да, Вы — лирик, однако. Может быть в отношениях с соседом по дому или парте можно верить и просто дружить. Стартап, как и любой бизнес, не предполагает такие понятия, как дружба, любовь и прочие «слияния». Бизнес — это договор с четким алгоритмом и распределением ролей. Иначе то и будет: напряжение — конфликт — мордобой.
То, как вы будете себя вести на эмоциональном уровне, не зависит от того, что вы юридически что-то закрепите
Извините, но это заблуждение. Договор — это не просто юридическая бумажка. Он закрепляет то, о чем стороны договорились, в том числе и о том, что и как делать в случае разногласий. Если он закреплен письменно, то психологически проще жить, зная, что нарушение договора будет для всех очевидным фактом.
Работайте так, чтобы о договоре никто и не вспоминал, и все будет нормально.
А что такое «большое количество»? Это сколько? Тысяча, миллион, миллиард? Вот в нашей ФНС запущена система, которая обрабатывает 15 млрд счетов фактур в год! Если тупо рассчитать сколько это в секунду, то получится 476 документов. Для обеспечения этого потока построен отдельный ЦОД. Т.е. в автоматизированной системе чтобы большое стало маленьким надо добавить памяти, процессоров, тактовой частоты, параллельные вычисления и т. п. Вот и всё.
Здесь непонятно другое: почему у «крупнейшего ритейлера в РФ и Европе» столько неавтоматизированного бумажного документооборота? И что делает его ERP-система?
Повторяю, что описанная проблема продавца — банальная. И средства ее решения давно известны и применялись еще до эпохи роботов, ИИ, BI и прочих новомодных фишек.
Предполагаю, что в IBS есть соответствующее подразделение, и они просто нашли объект, на котором можно потренироваться. А я против этого ничего не имею. Только не надо из этого делать спер-пупер достижение. Технической стороны дела я не касаюсь, может оно действительно крутое.
Коллеги, кого вы собираетесь учить? Разработчика, как заявлено в самом начале этого сообщения. Тогда, что вы понимаете под этим термином? Разработчик — это кто? Школьник-оболтус, или человек, который уже что-то разработал? Тогда вопрос: как он умудрился что-то разработать, если до сих пор не знает «Чему именно учиться?» и где его «рельсы»?
Не кажется ли вам, что человеку, который не знает, где его «рельсы», максимум, что светит — это путевым обходчиком, и то только эти рельсы таскать?
И вообще, не оскверняйте понятие «разработчик». На Хабре в последнее время (а может и всегда так было) появились куча сообщений в которых постоянно под этим понятием понимаются какие-то недоумки, которых только и надо то контролировать, то пинать, то поучать.
Разработчик — «это звучит гордо». Это еще Максим Горький сказал сто лет назад. Потому что он всегда и постоянно учится. Иначе это не разработчик.
Тема интересная, но прочитал до ката и не знаю читать ли далее?
Ощущение роста напряжения между вами и вашим сооснователем – это нормальная, здоровая и ожидаемая ситуация. Вам следует ожидать, что в какой-то момент вам придется покон-фликтовать со своим сооснователем, поскольку при создании стартапа ваши точки зрения и личностные особенности неизбежно будут сталкиваться
Возможно это и нормальная ситуация (это индивидуально), но назвать ее здоровой и ожидаемой – это уже слишком. Если ожидаешь неприятность, то обязательно ее получишь! Это одна сторона дела, а другая – раз ожидаешь конфликт, значит сам где-то нашкодил! Повинись или уходи! И ничего нормального и тем более здорового в этом нет!
В любой момент между сооснователями могут возникнуть споры касательно распределения долей, ролей и обязанностей, стратегий найма и разработки продуктов, взаимной продуктивности – или из-за всего сразу!
Вот споры – это действительно нормально. Но причем тут конфликты и рост напряжения? Спор и конфликт — это совершенно разные понятия.
А у Вас нет определений. Например, что такое стартап? Получается, что он свалился на сооснователей откуда-то сверху, может с неба или с потолка. А на самом деле это в первую очередь договор между сооснователями, даже если он устный. Но договор! Закрепите его на бумаге и все перечисленные проблемы не будут вызывать ощущения напряжения!
Казалось бы, про роботов очень актуально и интересно. Но с трудом пролистал до конца, потому что не мог понять зачем? Задача настолько древняя (в масштабе ИТ) и банальная, что никак не ожидал, что ее до сих пор решают и при этом применяют такие нетривиальные способы. Может не надо было огород городить?
Итак, задача:
Это фантастическое количество товаров, поставщиков, поставок — и связанного с ними документооборота, которого с каждым месяцем становится больше и больше.
Большая часть документов проходит по ЭДО. Но в нем работают не все поставщики, и бремя сверки бумажной документации перед оплатой ложится на плечи бухгалтеров. Совсем не редки случаи, когда цены в заказах и документах на оплату разнятся, причин расхождения может быть много. При этом объем документооборота растет, и этот процесс превращается в ужас-ную механическую кабалу для целого штата бухгалтеров-сверщиков
Банальность проблемы автор признает:
Схема очень простая и расхожая: ритейлер формирует заказ на поставку товаров в свои магазины, после его доставки поставщиком производится приемка и после обработки документов — оплата
Лет 20-25 – это действительно была большая задача. Но сейчас то чего…?
Причем тут бухгалтера? Бухгалтерия к процессу торговли не имеет никакого отношения. А в любой нормальной торговой программе менеджер видит всю подноготную операции и в том числе все счета, накладные, движение товаров, оплату и т.д. Откуда может взяться «механическая кабала для целого штата бухгалтеров»?
Далее еще интересней:
Как видите, большая часть этого процесса — механическая рутина. Идеальная цель для автоматизации! Однако классический путь доработки ERP-системы с интеграцией ее с СХД был заказчику закрыт…
Оказывается, есть ERP-система. Можно было бы и без ERP обойтись, но тем лучше – значит в системе обязательно есть средства автоматизации торговых операций. Непонятно, правда, причем тут ее интеграция с СХД? И почему заказчику был закрыт доступ к системе? непонятно, имеется ввиду, что заказчик — это владелец системы или покупатель? Ну да ладно. Очевидно, что ядро проблемы – человеческий фактор.
Так может надо просто сменить тех, кто внедрял и так неумело поддерживает систему. Иначе где гарантия, что роботы будут внедрены оптимальным образом!
Эту задачу тоже никто не устанавливал, как и любую другую.
Эту задачу не надо никому устанавливать — она у нас в инстинктах, и более того, выжить — это главный инстинкт любого организма. А у человека даже сформирован социальный инстинкт, который не раз спасал человечество.
Это с чего вообще?
Странный вопрос: медицинская генетика только этим и занимается, и этого никто не скрывает, хотя и не афишируют. Читайте.
Сам не исследовал, но это видно невооруженным взглядом. Тем более за последние лет 40.
Жаркая дискуссия, только не пойму о чем? Ну вот с чего вы взяли, что
Поиск внеземной жизни и установление контакта — одна из самых важных задач, которые стоят перед человечеством.
? Кто это установил? Кому это нужно? Ну, посмотрите или послушайте новости, почитайте ленты новостей: Сохранение земной жизни — одна из самых важных задач, которые стоят перед человечеством!
Вот это действительно проблема! Человек вышел из процесса естественной отбора. Вот это проблема! Если в течение следующих 40-50 лет генетики не смогут решить проблему генетических заболеваний, то половина рожденных будет приспособлено к жизни только в искусственных условиях с соответствующей химической, механической и психологической поддержкой. А также с соответствующей финансовой поддержкой!
А еще через 50 лет уже некому будет оказывать эту поддержку. Может это и хорошо, т.к. на ядерную кнопку некому будет нажать, но это значит, что кнопка будет нажата случайным образом.
Инопланетяне не смогут определить, что на Земле есть разумная жизнь. А вы собираетесь искать ее где-то в другом месте. Пока смешно, а что будет далее? Время покажет.
Будьте здоровы и рожайте здоровых детей!
Размножайтесь, господа, размножайтесь!
Успехов.
Если продукт свой, заказчика нет и нужно запустить быстро, без выделения времени на описание, то, например, встроенные комментарии в код спасают.
Заказчик есть всегда! Это не только функция, но и роль, которую может играть даже член команды проекта. Я уверен, что «заказчики» есть и Вашей команде, только Вы их таковыми не считаете. И зря. Можно специально назначать такого «заказчика» и увидите, что он значительно поднимет вам качество работы.
А комментарии в коде — это элемент стиля программирования, это отношение программиста к своему коллеге, которые возможно будет разгребать написанное. Относитесь к нему уважительно, и Вам будет приятно работать, да и, как знать, может через годик-другой самим придется разгребать свое творчество.
Главная мысль статьи — смотреть на масштаб проекта. Не всегда экономически целесообразно сразу выделять ресурс на документирование и заказчика не убедить.
Документирование — это не вопрос экономической целесообразности. Это вопрос качества работы команды проекта, и в этом вопросе надо не заказчика убеждать, а себя, если это еще не стало у вас нормой.
А качество, естественно, косвенно, но влияет и на экономику проекта, и очень даже часто, сильно влияет. И качество работы уж совсем не зависит от масштаба проекта. Как известно ложка дегтя может испортить бочку меда! Хотите долго задержаться на рынке — повышайте качество работы и даже на мелких проектах. Более того, беритесь за проекты, которые завалили ваши конкуренты. Это самая интересная и благодарная работа.
Требования, конечно, тоже документация, но не всегда в том объеме, чтобы помочь разобраться — как работает система. К тому же, в ходе разработки, требования имеют свойство меняться и уточняться...
Согласен. Часто заказчик сам не понимает чего хочет, но еще чаще, он не понимает возможностей автоматизации. Поэтому относитесь к требованиям заказчика, как к своим. Для этого есть прекрасный механизм, например, обследование бизнес-процессов заказчика. По результатам обследования вместе проведете оптимизацию и напишете новые требования и ТЗ. Тогда они уже не будут меняться и уточняться. А если и будут, то только совершенствоваться.
Такая вот грустная практика до сих пор существует.
Все в ваших руках и мозгах! Поверьте, проектирование — это не только интересно, но и весело! Особенно на незнакомом объекте. Нет ничего более интересного, чем процесс познания нового.
Но хорошее ТЗ, написанное совместно с заказчиком, это не только чувство удовлетворения от хорошо сделанной работы, но это и еще эффективное средство повышения производительности труда программиста — это его шпаргалка, или даже настольная книга до самого окончания проекта. Если будете писать такие ТЗ, то всей команде будет весело. И заказчик легче будет подписывать счета на оплату.
Проектируйте, господа, проектируйте!
В том то и дело, что все, что Вы перечислили делалось сугубо из практических соображений, и главное несло огромную пользу. Это уже потом поэты расцветили эти события метафорами. Все эти открытия — борьба за еду или ее денежный эквивалент.
Так и здесь, будет угроза жизни — полетим на край вселенной. А пока «нас и тут неплохо кормют».
Очень хороший пример, только он подтверждает обратное. Вы плохо знаете собак: они гавкают только когда хозяин дома. Так она показывает ему, что не зря ест его хлеб. Но главное знает, что есть за кого спрятаться. А у человечества есть такой хозяин?
Основной миф на эту тему - само понятие "искусственный интеллект". Чтобы это понять, достаточно прочитать, что такое интеллект: "Интелле́кт или ум — качество психики, состоящее из способности осознавать новые ситуации, способности к обучению и запоминанию на основе опыта, пониманию и применению абстрактных концепций, и использованию своих знаний для управления окружающей человека средой".
В этом определении главное, что интеллект - это свойство психики! После этого можно закрывать все рассуждения об искусственном интеллекте. Но еще одно свойство интеллекта, которое отличает его например от разумного поведения животных. Это - управление окружающей средой. Именно управление, т.е. анализ ее и изменение под свои потребности. Естественно, что у нынешних программ, которые отнесены к этом виду ПО, нет своих потребностей и они не изменяют окружающую среду.
Таким образом, скажем так, компьютерного интеллекта не существует и в ближайшей перспективе не предвидится. Но, как программный продукт, т.е. товар, "искусственный интеллект" существует и продается очень даже хорошо благодаря агрессивной рекламе. А почему бы и нет.
М-да! Что называется приехали. Времена меняются и с этим ничего не поделаешь. А можно ли при таком целеполагании достичь главного - счастья?
Все же по старинке рекомендую цели: построить дом, посадить дерево и вырастить сына.
Это древняя мудрость, вернее ее интерпретация, но это не важно. Конечно, "дом" - это не особнячок в 4 - 10 - 20... стен. Дом - это место, где будет расти твое дерево и твое дитя.
Это же и алгоритм действий. Или как пишет автор "фильтр".
Только достижение этих целей приводит к счастью. Вот этого всем и желаю.
Ставьте правильные цели и тогда не придется писать "я засел один в пустой квартире" .
Ну, так включите. И тогда Вы поймете, что написали не о рисках, а о каких-то текущих проблемах. Отличие: риск - это события во внешней среде (обычно), на которую Вы можете оказать небольшое влияние. А проблемы - это события в Вашей обстановке, которую Вы сами формируете. Риски надо обходить, а проблемы - решать и желательно до начала проекта.
И не надо "упрощать реестр рисков" - попробуйте их не придумывать.
Я старый разработчик и все эти рассуждения для меня настолько банальны, что задаюсь вопросом: неужели всё так деградировало, что эти банальности обсуждаются в статьях, блогах и т.д. Я бы постеснялся выкладывать на свет божий свою некомпетентность.
Ребята, а не пробовали уяснить такие понятия, как "проект", "управление проектом"? Не пробовали писать техническую документацию? Или вера не позволяет? Я имею в виду эджайл.
У Вас нет формулировки понятия "риск". Все, что вы включили в перечень "рисков" к рискам никакого отношения не имеет. Это обычные технические и организационные проблемы. Впрочем, их даже проблемами назвать трудно, так как они связаны с плохим управлением проектом или даже просто с разгильдяйством сотрудников и, в первую очередь, руководителя проекта (РП).
В Вашем случае риск один - РП не хватает квалификации.
С большинством Ваших рассуждений согласен, но Вы повторяете принципиальную ошибку многих авторов, пишущих на эту тему – ошибка в назначении ТЗ. Вы пишите:
Кому будет полезна статья:
представителям заказчиков …;
тендерным специалистам со стороны как заказчика …;
заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).
И при этом забываете, что сущность ТЗ заключается в самом названии этого документа –задание кому? Заказчику? Абсурд! ТЗ на АС – это задание программистам, в широком понимании. Т.е. это задание ИТ-специалистам, которые непосредственно будут выполнять разработку системы. ТЗ – это настольная книга для программиста, и прежде чем что-то накодить, он должен посмотреть в ТЗ.
Соответственно этому и писать ТЗ надо, как задание программисту. Тогда становится ясно, что из всей проектной документации ТЗ присутствует ВСЕГДА! Печати и подписи начальников не всегда обязательны, но нормальный программист ВСЕГДА хоть на полстраницы, сделает его для себя, прежде чем что-то закодировать.
А ГОСТ 34 до сих пор живой, потому что в нем заложен универсальный алгоритм мышления человека. Что бы вы не делали, хоть табуретку, хоть полет на Марс, вы будете мыслить по этому алгоритму. Все прочие методологии используют этот же алгоритм и отличаются в мелочах.
Вот только системным и логическим мышлением не каждый специалист обладает. Плюс лень-матушка: как не хочется тратить свое драгоценное время на писанину. Да и литературные способности не помешали бы. Поэтому за четверть века своей работы я видел единицы хороших ТЗ. Приходится самому писать или переписывать. Но оно того стоит!
Во-первых, что такое «влиться в сферу IT»? Если сотрудник разгружает коробки с IT-техникой у клиента, это считается, что он «влился»? А водитель, который привез эту технику, «влился»? А тот же сотрудник воткнул вилку принтера в розетку и установил драйвер? А официант на своем мобильнике принял заказ и оплату, он «влился в сферу IT». И т.д.
Во-вторых, и это главное. Далеко ходить не будем, а посмотрим в Википедии, что такое «образование»:
«Образова́ние — система воспитания и обучения личности, а также совокупность приобретаемых знаний, умений, навыков, ценностных установок, функций, опыта деятельности и компетенций. В широком смысле слова, образование — процесс или продукт формирования ума, характера и физических способностей личности.»
Ключевое здесь — это «воспитание и обучение личности» и прочее можно назвать кругозором. Формировать личность можно только при общении Учителя с учеником и только очно, хотя бы на первом этапе. По любому разделу обучения есть десятки, может быть, тысячи учебников и авторитетов, а Учитель десятикратно сокращает пустую работу поиска нужного и полезного, предлагая свой метод, знания, навыки… Раньше это называлось научной школой.
Можно ли это все получить самостоятельно? Можно, и это очевидно и не требует доказательств, но эффективность такого обучения (соотношение времени обучения к времени поиска и освоения нужного из моря информации) — чуть выше нуля. С Учителем — приближается к единице, но остальное — самостоятельная работа!
Тот, кто УЧИЛСЯ в универе, тот помнит, сколько «ненужного» приходилось учить! Казалось зачем? И только получив свой опыт, начинает доходить для чего это надо было. Если что-то пропустил по молодости и глупости, изучаешь самостоятельно. И здесь самое главное, что образование позволяет самостоятельно определить, что еще тебе надо и с какой глубиной.
Ну, и последнее, это в-третьих. Самостоятельно можно научиться кодить что-нибудь. А, если надо прочитать технический проект, или даже техзадание? Т.е. надо понять, как твой кусок программы влияет на результат работы всей системы?
А если ты проектируешь многопрофильную систему? Необходимо знание процессного управления. А здесь без широкого кругозора не обойтись, т.к. на входе один продукт и поставщики, на выходе другой продукт и потребитель, между ними процесс. Все компоненты процесса надо не только знать, но и понимать их природу. Можно научиться делать обследование самостоятельно? Думаю можно за несколько лет набивания шишек, которые на практике выражаются в штрафных санкциях и судебных издержках.
Поэтому проблема, как учиться в ВУЗе или самостоятельно — это надуманная проблема. Без университета быстро стать высококлассным специалистом трудно, еще труднее стать руководителем высшего уровня. Но самостоятельное обучение — это стезя любого классного специалиста до самого гроба!
Извините, но это заблуждение. Договор — это не просто юридическая бумажка. Он закрепляет то, о чем стороны договорились, в том числе и о том, что и как делать в случае разногласий. Если он закреплен письменно, то психологически проще жить, зная, что нарушение договора будет для всех очевидным фактом.
Работайте так, чтобы о договоре никто и не вспоминал, и все будет нормально.
Здесь непонятно другое: почему у «крупнейшего ритейлера в РФ и Европе» столько неавтоматизированного бумажного документооборота? И что делает его ERP-система?
Повторяю, что описанная проблема продавца — банальная. И средства ее решения давно известны и применялись еще до эпохи роботов, ИИ, BI и прочих новомодных фишек.
Предполагаю, что в IBS есть соответствующее подразделение, и они просто нашли объект, на котором можно потренироваться. А я против этого ничего не имею. Только не надо из этого делать спер-пупер достижение. Технической стороны дела я не касаюсь, может оно действительно крутое.
Не кажется ли вам, что человеку, который не знает, где его «рельсы», максимум, что светит — это путевым обходчиком, и то только эти рельсы таскать?
И вообще, не оскверняйте понятие «разработчик». На Хабре в последнее время (а может и всегда так было) появились куча сообщений в которых постоянно под этим понятием понимаются какие-то недоумки, которых только и надо то контролировать, то пинать, то поучать.
Разработчик — «это звучит гордо». Это еще Максим Горький сказал сто лет назад. Потому что он всегда и постоянно учится. Иначе это не разработчик.
Возможно это и нормальная ситуация (это индивидуально), но назвать ее здоровой и ожидаемой – это уже слишком. Если ожидаешь неприятность, то обязательно ее получишь! Это одна сторона дела, а другая – раз ожидаешь конфликт, значит сам где-то нашкодил! Повинись или уходи! И ничего нормального и тем более здорового в этом нет!
Вот споры – это действительно нормально. Но причем тут конфликты и рост напряжения? Спор и конфликт — это совершенно разные понятия.
А у Вас нет определений. Например, что такое стартап? Получается, что он свалился на сооснователей откуда-то сверху, может с неба или с потолка. А на самом деле это в первую очередь договор между сооснователями, даже если он устный. Но договор! Закрепите его на бумаге и все перечисленные проблемы не будут вызывать ощущения напряжения!
Итак, задача:
Банальность проблемы автор признает:
Лет 20-25 – это действительно была большая задача. Но сейчас то чего…?
Причем тут бухгалтера? Бухгалтерия к процессу торговли не имеет никакого отношения. А в любой нормальной торговой программе менеджер видит всю подноготную операции и в том числе все счета, накладные, движение товаров, оплату и т.д. Откуда может взяться «механическая кабала для целого штата бухгалтеров»?
Далее еще интересней:
Оказывается, есть ERP-система. Можно было бы и без ERP обойтись, но тем лучше – значит в системе обязательно есть средства автоматизации торговых операций. Непонятно, правда, причем тут ее интеграция с СХД? И почему заказчику был закрыт доступ к системе? непонятно, имеется ввиду, что заказчик — это владелец системы или покупатель? Ну да ладно. Очевидно, что ядро проблемы – человеческий фактор.
Так может надо просто сменить тех, кто внедрял и так неумело поддерживает систему. Иначе где гарантия, что роботы будут внедрены оптимальным образом!
Странный вопрос: медицинская генетика только этим и занимается, и этого никто не скрывает, хотя и не афишируют. Читайте.
Сам не исследовал, но это видно невооруженным взглядом. Тем более за последние лет 40.
? Кто это установил? Кому это нужно? Ну, посмотрите или послушайте новости, почитайте ленты новостей:
Сохранение земной жизни — одна из самых важных задач, которые стоят перед человечеством!
Вот это действительно проблема! Человек вышел из процесса естественной отбора. Вот это проблема! Если в течение следующих 40-50 лет генетики не смогут решить проблему генетических заболеваний, то половина рожденных будет приспособлено к жизни только в искусственных условиях с соответствующей химической, механической и психологической поддержкой. А также с соответствующей финансовой поддержкой!
А еще через 50 лет уже некому будет оказывать эту поддержку. Может это и хорошо, т.к. на ядерную кнопку некому будет нажать, но это значит, что кнопка будет нажата случайным образом.
Инопланетяне не смогут определить, что на Земле есть разумная жизнь. А вы собираетесь искать ее где-то в другом месте. Пока смешно, а что будет далее? Время покажет.
Будьте здоровы и рожайте здоровых детей!
Размножайтесь, господа, размножайтесь!
Успехов.
Или что Вы понимаете под «шлаком»? И что такое у Вас «дока»?
А комментарии в коде — это элемент стиля программирования, это отношение программиста к своему коллеге, которые возможно будет разгребать написанное. Относитесь к нему уважительно, и Вам будет приятно работать, да и, как знать, может через годик-другой самим придется разгребать свое творчество.
Документирование — это не вопрос экономической целесообразности. Это вопрос качества работы команды проекта, и в этом вопросе надо не заказчика убеждать, а себя, если это еще не стало у вас нормой.
А качество, естественно, косвенно, но влияет и на экономику проекта, и очень даже часто, сильно влияет. И качество работы уж совсем не зависит от масштаба проекта. Как известно ложка дегтя может испортить бочку меда! Хотите долго задержаться на рынке — повышайте качество работы и даже на мелких проектах. Более того, беритесь за проекты, которые завалили ваши конкуренты. Это самая интересная и благодарная работа.
Согласен. Часто заказчик сам не понимает чего хочет, но еще чаще, он не понимает возможностей автоматизации. Поэтому относитесь к требованиям заказчика, как к своим. Для этого есть прекрасный механизм, например, обследование бизнес-процессов заказчика. По результатам обследования вместе проведете оптимизацию и напишете новые требования и ТЗ. Тогда они уже не будут меняться и уточняться. А если и будут, то только совершенствоваться.
Все в ваших руках и мозгах! Поверьте, проектирование — это не только интересно, но и весело! Особенно на незнакомом объекте. Нет ничего более интересного, чем процесс познания нового.
Но хорошее ТЗ, написанное совместно с заказчиком, это не только чувство удовлетворения от хорошо сделанной работы, но это и еще эффективное средство повышения производительности труда программиста — это его шпаргалка, или даже настольная книга до самого окончания проекта. Если будете писать такие ТЗ, то всей команде будет весело. И заказчик легче будет подписывать счета на оплату.
Проектируйте, господа, проектируйте!
Так и здесь, будет угроза жизни — полетим на край вселенной. А пока «нас и тут неплохо кормют».