Почему так долго и дорого? Рассказываю, о процессе web разработки; Как и почему простые (с точки зрения клиента) задачи могут требовать сотен и тысяч долларов для реализации. Что же делают эти программисты? #webdevelopment #программирование #вебразработка #бизнес #ruby #javascript #software - ИНСТА: instagram.com/zykin.ilya - ГИТХАБ: github.com/the-teacher - ТЕЛЕГА: t.me/prostocoding - LINKEDIN: www.linkedin.com/in/ilya-zykin 00:00 - Приветствие. "Как муха превратилась с Слона" 00:26 - История начинается 01:26 - Шаг 1. Тимлид формирует задачу 03:03 - Шаг 2. Система наносит ответный удар 05:45 - Торг и согласование (тимлид-команда) 06:32 - Шаг 3. Клиентский запрос 07:59 - Шаг 4. Предложение об унификации решения 09:23 - Шаг 5. Согласование подходов 10:43 - Шаг 6. Реализация на backend 11:45 - Шаг 7. Корректировка системы на backend стороне 13:30 - Шаг 8. Реализация на Front-end стороне 15:11 - Шаг 9. Подготовка к релизу и QA 16:46 - Подводим итоги 17:41 - Считаем организационные затраты 19:45 - Оставьте ваши комментарии, обсудим.
Именно для этого нужны 2 буквы - СА [Системный Аналитик], который сразу проектирует систему согласно требованиям клиента и ставит задачи разработчикам)
Только дослушал до момента с изменением бэкэнда. Звучит как критическая ошибка, единнойой точкой правды должна быть бд(если без кэшей). Нужно плясать от данных, приходящих из апи, клиент должен их форматиртвать сам. Очевидно, что при изменении формата вывода придется менять его на всех клиентах, но в таком случае мы хотя бы не мешаем слои отображения данных и слои хранения А ваша схема - это бомба с часовым механизмом, которая не ясно когда отстрелит вам ногу, при том одновременно на всех клиентах
Досмотрел до изменений на бэке, понял что нет смысла вам объяснять про слои. Вы интерфейс поменяли, убили обратную совместимость. Всё клиенты на старых версиях - легли. Мрак
За последние 15 лет я, пожалуй, ни разу не встречал ситуации, когда проектирование помогало избежать все возможные проблемы. Это не работало ни в строительстве, ни в продажах, ни в ИТ, ни в преподавании. Сколько бы детальная аналитика и проектирование не были, они никогда не доходят до настолько мелких деталей. Допустим, вы запланировали ремонт, проанализировали все лучшие решения, выбрали все материалы, сделали идеальный проект. А по факту, в день заливки полов оказалось, что нужной смеси для полов нигде нет, и нужно на лету, по необходимости, решать возникшую ситуацию. Покупать другую смесь, другую марку инструмента, подгонять привычную технологию под текущие обстоятельства с учетом ошибок исполнителей.
В программировании 1 строчка кода может стоить 1 млн, если она решает проблему на 1 млн для какой нибудь крупной компании. И 1 млн строк кода могут ничего не стоить, если это тех решение никому не нужно.
У Брукса в книге "Мифический человеко-месяц" была описана такая ситуация. Пишу по памяти, поэтому цифры могут быть неточные, но суть передам. Там делали большую программу (где-то начало 70-х годов), команда 1000 человек, делали 3 года. Итого 3000 человеко-лет. Очень много бюрократии было: начальники отделов, согласования, куча бумаг распечатанных и т.д. При этом, если бы делали небольшой командой в 10 человек из гениальных программистов, которые бы делали в 5 раз быстрее, то разработка такой программы заняла бы 10 лет. Но без бюрократии. А для бизнеса 3 года и 10 лет это очень большая разница. Поэтому выбрали первый вариант. Тут примерно также получается. Можно разрабатывать быстро, но есть предел, после которого или проект готов, или его надо закрывать, или он начинает сильно разрастаться. Скорее всего, это не только программирования касается.
@@m889k коммуникация и процессы сжирают тонну времени, денег, всех возможных ресурсов. Это накладные расходы организаций. Об этом мало кто думает. Пример вполне реальный, хоть и художественно оформленный. Технари, конечно, сфокусированы на своих чисто технических моментах. А вот бизнес хочет понимать, что там эти технари делают и почему они просто не могут добавить 2 буквы. А оказывается, это и впрямь может оказаться не банально. О том и история.
Почему так долго и дорого? Рассказываю, о процессе web разработки; Как и почему простые (с точки зрения клиента) задачи могут требовать сотен и тысяч долларов для реализации. Что же делают эти программисты? #webdevelopment #программирование #вебразработка #бизнес #ruby #javascript #software
- ИНСТА: instagram.com/zykin.ilya
- ГИТХАБ: github.com/the-teacher
- ТЕЛЕГА: t.me/prostocoding
- LINKEDIN: www.linkedin.com/in/ilya-zykin
00:00 - Приветствие. "Как муха превратилась с Слона"
00:26 - История начинается
01:26 - Шаг 1. Тимлид формирует задачу
03:03 - Шаг 2. Система наносит ответный удар
05:45 - Торг и согласование (тимлид-команда)
06:32 - Шаг 3. Клиентский запрос
07:59 - Шаг 4. Предложение об унификации решения
09:23 - Шаг 5. Согласование подходов
10:43 - Шаг 6. Реализация на backend
11:45 - Шаг 7. Корректировка системы на backend стороне
13:30 - Шаг 8. Реализация на Front-end стороне
15:11 - Шаг 9. Подготовка к релизу и QA
16:46 - Подводим итоги
17:41 - Считаем организационные затраты
19:45 - Оставьте ваши комментарии, обсудим.
Именно для этого нужны 2 буквы - СА [Системный Аналитик], который сразу проектирует систему согласно требованиям клиента и ставит задачи разработчикам)
Только дослушал до момента с изменением бэкэнда. Звучит как критическая ошибка, единнойой точкой правды должна быть бд(если без кэшей). Нужно плясать от данных, приходящих из апи, клиент должен их форматиртвать сам.
Очевидно, что при изменении формата вывода придется менять его на всех клиентах, но в таком случае мы хотя бы не мешаем слои отображения данных и слои хранения
А ваша схема - это бомба с часовым механизмом, которая не ясно когда отстрелит вам ногу, при том одновременно на всех клиентах
Досмотрел до изменений на бэке, понял что нет смысла вам объяснять про слои. Вы интерфейс поменяли, убили обратную совместимость. Всё клиенты на старых версиях - легли. Мрак
В этой проблеме следует учитывать, что при проектировании можно было поднять все эти вопросы и упростить)
За последние 15 лет я, пожалуй, ни разу не встречал ситуации, когда проектирование помогало избежать все возможные проблемы. Это не работало ни в строительстве, ни в продажах, ни в ИТ, ни в преподавании. Сколько бы детальная аналитика и проектирование не были, они никогда не доходят до настолько мелких деталей.
Допустим, вы запланировали ремонт, проанализировали все лучшие решения, выбрали все материалы, сделали идеальный проект. А по факту, в день заливки полов оказалось, что нужной смеси для полов нигде нет, и нужно на лету, по необходимости, решать возникшую ситуацию. Покупать другую смесь, другую марку инструмента, подгонять привычную технологию под текущие обстоятельства с учетом ошибок исполнителей.
В программировании 1 строчка кода может стоить 1 млн, если она решает проблему на 1 млн для какой нибудь крупной компании. И 1 млн строк кода могут ничего не стоить, если это тех решение никому не нужно.
У Брукса в книге "Мифический человеко-месяц" была описана такая ситуация. Пишу по памяти, поэтому цифры могут быть неточные, но суть передам. Там делали большую программу (где-то начало 70-х годов), команда 1000 человек, делали 3 года. Итого 3000 человеко-лет. Очень много бюрократии было: начальники отделов, согласования, куча бумаг распечатанных и т.д. При этом, если бы делали небольшой командой в 10 человек из гениальных программистов, которые бы делали в 5 раз быстрее, то разработка такой программы заняла бы 10 лет. Но без бюрократии. А для бизнеса 3 года и 10 лет это очень большая разница. Поэтому выбрали первый вариант. Тут примерно также получается. Можно разрабатывать быстро, но есть предел, после которого или проект готов, или его надо закрывать, или он начинает сильно разрастаться. Скорее всего, это не только программирования касается.
@@m889k коммуникация и процессы сжирают тонну времени, денег, всех возможных ресурсов. Это накладные расходы организаций. Об этом мало кто думает. Пример вполне реальный, хоть и художественно оформленный. Технари, конечно, сфокусированы на своих чисто технических моментах. А вот бизнес хочет понимать, что там эти технари делают и почему они просто не могут добавить 2 буквы. А оказывается, это и впрямь может оказаться не банально. О том и история.
@@m889k спасибо за комментарий. Пришелся очень кстати и точно по теме.
Какая боль... Какая боль...