Ну тут уже вина самих управляющих что пролюбили и техническую документацию, и проект и людей с экспертизой и доступы к системам контроля версий, серверам и всему остальному.
Имея хотя-бы эти диаграммы и много времени — возможно пусть с усилиями написать проект еще раз. Да он будет другой, да будет потеряна куча времени и нет гарантий результата. Если даже их нет — тогда вообще все придется начинать с нуля если у фирмы есть еще финансы.
О отлично — то есть этому разработчику было предоставлены схемы процессов, но вместо того чтобы по ним составить спецификацию и написать нормальный код и документацию к нему обновлять регулярно.
Разраб просто фигачил задачи самым удобным способом, и мало того что ему за это никто не дал по рукам — так как никто не ревью его кода.
Основная команда разработки занималась не пойми чем и офигела на столько, что не заметила как со стороны в их проект заливались тонны не самого лучшего кода которые его и погребли а когда заметили — ничего лучшего чем указать на единственного кто хоть что-то на этом проекте делал пальцем и сказать — чей коммит последний тот и крайний и тем более он уходит — так что точно крайний не смогла.
Менеджеры всему этому попустительствовали максимально экономя на персонале, так что не было архитектора или сеньора который бы прописал целебных пинков и эффективным менеджерам и страдающей фигней команде и активному быдло-кодеру.
И все это понятное дело привело в серьезным потерям и простоям.
Да — тут точно виноваты созвоны и наличие диаграммы процессов!
Заведите какой-нибудь трекер задач (мы используем Доски в Gitlab из Issue), необходимость созвона он не решает, но необходимость дергать вас каждые пол часа желая узнать готово или нет — он убирает, на доске сразу видно что еще не начинали, что начали, что на тесте и что на демо и что уже зарелизили.
Записывайте время которое тратите на такие бессмысленные followup и потом в конце месяца выскажите CEO/CTO или главному менеджеру что на тупые вопросы вы тратите 10 часов в неделю и еще 5 на то чтобы вернуться к задаче так что треть недели выкинута в пустую.
Задавайте а лучше запишите 100500 своих вопросов к самим менеджерам и скажите что мол я ничего не могу сделать пока мы не решим эти вопросы — вы пока решайте а я пойду покурю/займусь другой задачей/хабр почитаю.
Попросите выделить одного из них для того чтобы заполнять все задачи в трекере и отфутболить особо наглых индивидуумов которым нужно срочно всё вчера и от вас — пусть они парят мозг другому менеджеру а он разберет их бредни на простой список задач для вас.
И вот уже мячик на их стороне и они бурно имитируют деятельность по обработке запросов отдела разработки.
Многие даже выдают необычные решения и делают кое-какую небольшую рутинную для разработчика но привычную для клерка полезную работу.
(заполняют таблицу с ключами переводов для сайта или рисуют диаграмму бизнес-процессов, или пишут документацию).
Выбивает из работы кого?
ProjectManager или ProjectOwner задача собственно которых вести проект в том числе и отвечать на глупые вопросы разработчиков из серии а как этот бизнес процесс должен работать в деталях?
Админа который вечно не доступен в slack и еще не знает что у него сервер упал а рутовые права на него он не дал никому?
Или менее опытного коллегу который пишет 100500 вопросов о том что ему надо сделать и как?
Да свое время я еще как ценю ибо оно хорошо оплачивается по меркам моего небольшого города, ценю и время других стараясь не дергать их в slack по каждому вопросу а набираю таких вопросов штук 5-10 и после этого детально разбираем каждый.
Звоню в slack если человек свободен (если ты не можешь принимать звонки — будь добр выстави статус не трогать меня 1/2/4/8 часов). Большинство таки этот статус ставят и он блокирует автоматом уведомления о новых сообщениях и блокирует все входящие звонки.
Как вы ловко записали людей которым тяжело воспринимать много текстовой информации в категорию альтернативно-одаренных.
Но предполагаю что такое деление не совсем корректно, так как нет четкого разделения — скорее довольно большая градация. Например куда отнести меня — человека у которого зрение не 100% зрение, но и не настолько плохое чтобы носить очки. Однако на большем объеме текста глаза начинают уставать.
Еще есть разные типы людей — кто-то хорошо обрабатывает текстовую информацию. Кто-то звуковую, некоторые же видео-информацию, а есть и индивиды которые хорошо обучаются только при передачи информацию в живую персонально.
Еще не будем забывать о том что текстовая передача информации в сети как таковая (а до этого в книжном формате) была обусловлена в первую очередь дороговизной либо невозможностью передачи информации в ином варианте. (До сих пор помню ламповые звуки dialup и выключенные изображения в браузере, и загрузку картинки 20 минут). Отцы же вспомнят особенности проявки пленки для которой нужна чуть ли не целая лаборатория или хотя-бы куча реактивов и большой шкаф.
Сейчас же передача информации в виде аудио и видео формате стала проще текстовой передачи и возможно в некоторых случая и дешевле (время на набор текста, вычитка, коррекция, локализация, вставка поясняющих изображений). Так что естественно что визуальные и аудио форматы во многих сферах вытесняют и вытеснили текст.
Так что не нужно удивляться тому факту что на ТЕКСТОВУЮ RPG вроде GodVille было и есть отличное подробное текстовое описание. На 2D аркады вроде "Косморейнджеров" немного текста и куча скринов а на современные игры Let's Play на YouTube/Twitch.
Плюс наглядность и простота информации в таких форматах действительно более доступна. (Например мне иногда проще просмотреть BPMN диаграмму чем лезть в код и пытаться вспомнить как и что там работает в том модуле который 2 года собирал пыль)
Лично сам наоборот предпочитаю созвоны, если нужно что-то уточнить по задаче то у тебя выбор — писать несколько портянок текста чтобы человек понял сперва контекст потом сам вопрос. Если человек не понял вопрос — опять начинаем сначала а после еще и уточнение.
Плюс если вопрос нужно решить вот прям сейчас — то лучше подойти лично к человеку если вы в одно офисе, если нет — то одни звонок и вопрос решен.
То что заняло минут 30 — 60 занимает 5-15 минут. Так как при звонке явно инициируется коммуникация которую сложно прервать.
С текстом человек может прочитать сообщение и дальше заниматься своими делами, и может быть потом он о нем вспомнит и ответит. Но чаще всего — игнор.
И да я разработчик и да я интроверт и в принципе против любых излишних коммуникаций в любом виде.
Тут думаю важно понимать что разрабатываем, если лендинг или интернет магазин — то действительно на кой нам детальная спецификация проекта.
Точнее спецификация есть — это выписка из брифа с клиентом которая по сути и тз и спецификация.
Другое дело если мы делаем какую либо небольшую информационную систему. Тут уже нужны спецификации — но не обязательно делать их на всю систему — достаточно на критичные модули. Остальное на салфетке и скрины салфетки в систему документации.
Если же нам нужна отказоустойчивая, масштабируемая, инфраструктурная и стабильная система — вроде тех что запускают ракеты/управляют самолетами, кораблями, поездами, линиями связи/медицинская система.
Тут уже полу-мерами не обойтись — ВСЯ система должна быть предварительно смоделирована от веб-портала до последнего микроконтроллера в датчике давления, ВСЕ реализации должны соответствовать спецификации чтобы дать гарантию этого — ВСЕ части системы должны быть обмазаны тоннами авто-тестов, защитным программированием и документацией.
В противном случае — получим кучу трупов, миллиарды баксов убытков и громкое судебное дело с несколькими пожизненными сроками.
Все что сложнее простого рисунка на салфетке, будет дичайшим оверхедом.
В принципе справедливо, но лучше все таки поместить эти записи в какую либо систему документации.
А так да, можно построить целую систему на бумаге но её еще нужно и реализовать, в итоге получается двойная работа, плюс при реализации всегда всплывают нюансы не учтенные в основной модели и нужно будет опять обновлять модель.
Можно создать систему которая на основе модели уже генерирует готовый софт. Правда из всех похожих систем я видел только OpenESB и Camunda Workflow Engine.
Первый имеет свой UI для создания модели а вторая использует BPMN и DMN.
Оно даже как-то работает но вот ресурсов на поддержку всего этого добра уходит знатное количество.
Есть бредовая идея взять все эти XML подобные аннотации от UML до WSDL и реализовать их в виде новой молодежной json-schema, дать на все это редактор который позволит накидывать эти схемы + вертеть их с каких хочешь ракурсов.
json-schema-hub который будет их хранить и несколько библиотек (автоматическая генерация структур, автоматическая интеграция) для кучи языков.
В итоге у нас буду в одном месте
форматы данных
форматы структур данных
схемы хранилищ данных
описания процессов над данными
ссылки на готовые реализации этих процессов на любой вкус и цвет
описания какие процессы на каком сервисе расположены
Успешный ещё как приносит, вот только результат данного решения виден ой в какой долгосрочной перспективе (3-5) лет. Так что многие руководители по ошибке относят его в квадрат "не срочное"|"важное" или даже "не важное".
И вот проходит эти пять лет и продукт вообще не куда не может двигаться, так как носители знания по проекту разбежалась так как уже замучил этот проект. Новые люди сбегают сразу после испытательного периода, старая команда постепенно тоже бежит с тонущего корабля.
В итоге у бизнеса остается три варианта — остановить развитие проекта и ждать пока первый конкурент выкинет их из рынка, выкинуть все что уже есть и начать заново, либо мучить труп нанимая персонал в 1.5-2 раза завышенной вилке.
Если у бизнеса осталась хорошая подушка финансов — то еще есть шанс выплыть. И вот тогда бизнес начинает понимать о важность рефакторинга и больше никогда не забывает.
Хорошо хоть кто-то пытается разобраться в вопросе технологического хаоса для того чтобы навести порядок.
В современном it мире очень много практики и довольно мало науки к сожалению.
Исследуя код и документацию мы может ответь на вопрос как сделана та или иная технология. Но как только поднимаешь вопрос почему это сделано так, а не иначе и есть ли обоснованная причина именно такой реализации — то в большинстве случаев это либо "сделали как получилось" либо "все так делают и мы так делаем" лишь некоторые проекты имеют под собой какой либо фундамент в виде исследований или хотя-бы нескольких итераций разработки и тестов которые доказывает что текущая реализация более-менее оптимальна.
Из за того что нет конкретного подхода в реализации то объяснить решение довольно проблемно — проще навесить ярлык в виде CloudComputing, BigData, AI, Blohchain Blockchain и тп.
Ну если процесс сборки очень хитрый с кастомными образами, кучей скриптов — то почему бы и нет, но ping + db так собирать это по моему перебор немного...
эмм забавно конечно, но что мешает добавить все эти команды как alias в .bashrc / .zshrc?
В этом случае даже не нужно make писать. Если проектов много можно даже и так:
Знавал я и людей которые умудрялись такое проделывать, проказники.
Вот есть инфоцигане, есть "эффективные менеджеры" а есть и техноцигане.
В общем пара таких "разработчиков". Один на java JavaEE другой на Delphi быстро за день-два пилили интерфейс софтины с кнопочками и парой обработчиков, устраивали демо и продавали фасад программы за пол ляма-лям рублей и потом в течени месяца абы как хреначили mvp которое собственно продали и самое смешное — серьезные компании таки покупали эту #!&$#...
В итоге код вообще становиться похожим на Vuex только в React
Единственное что может Vuex но не может нормально mobx-state-tree это нормальный вызов одних action из других. Но эта фича скорее костыль...
Ну тут уже вина самих управляющих что пролюбили и техническую документацию, и проект и людей с экспертизой и доступы к системам контроля версий, серверам и всему остальному.
Имея хотя-бы эти диаграммы и много времени — возможно пусть с усилиями написать проект еще раз. Да он будет другой, да будет потеряна куча времени и нет гарантий результата. Если даже их нет — тогда вообще все придется начинать с нуля если у фирмы есть еще финансы.
О отлично — то есть этому разработчику было предоставлены схемы процессов, но вместо того чтобы по ним составить спецификацию и написать нормальный код и документацию к нему обновлять регулярно.
Разраб просто фигачил задачи самым удобным способом, и мало того что ему за это никто не дал по рукам — так как никто не ревью его кода.
Основная команда разработки занималась не пойми чем и офигела на столько, что не заметила как со стороны в их проект заливались тонны не самого лучшего кода которые его и погребли а когда заметили — ничего лучшего чем указать на единственного кто хоть что-то на этом проекте делал пальцем и сказать — чей коммит последний тот и крайний и тем более он уходит — так что точно крайний не смогла.
Менеджеры всему этому попустительствовали максимально экономя на персонале, так что не было архитектора или сеньора который бы прописал целебных пинков и эффективным менеджерам и страдающей фигней команде и активному быдло-кодеру.
И все это понятное дело привело в серьезным потерям и простоям.
Да — тут точно виноваты созвоны и наличие диаграммы процессов!
XHTML в 2к20 еще не вымер?!
Я последний раз его лет эдак 7 назад трогал...
Заведите какой-нибудь трекер задач (мы используем Доски в Gitlab из Issue), необходимость созвона он не решает, но необходимость дергать вас каждые пол часа желая узнать готово или нет — он убирает, на доске сразу видно что еще не начинали, что начали, что на тесте и что на демо и что уже зарелизили.
Записывайте время которое тратите на такие бессмысленные followup и потом в конце месяца выскажите CEO/CTO или главному менеджеру что на тупые вопросы вы тратите 10 часов в неделю и еще 5 на то чтобы вернуться к задаче так что треть недели выкинута в пустую.
Задавайте а лучше запишите 100500 своих вопросов к самим менеджерам и скажите что мол я ничего не могу сделать пока мы не решим эти вопросы — вы пока решайте а я пойду покурю/займусь другой задачей/хабр почитаю.
Попросите выделить одного из них для того чтобы заполнять все задачи в трекере и отфутболить особо наглых индивидуумов которым нужно срочно всё вчера и от вас — пусть они парят мозг другому менеджеру а он разберет их бредни на простой список задач для вас.
И вот уже мячик на их стороне и они бурно имитируют деятельность по обработке запросов отдела разработки.
Многие даже выдают необычные решения и делают кое-какую небольшую рутинную для разработчика но привычную для клерка полезную работу.
(заполняют таблицу с ключами переводов для сайта или рисуют диаграмму бизнес-процессов, или пишут документацию).
В общем не можете победить — возглавьте )))
Выбивает из работы кого?
ProjectManager или ProjectOwner задача собственно которых вести проект в том числе и отвечать на глупые вопросы разработчиков из серии а как этот бизнес процесс должен работать в деталях?
Админа который вечно не доступен в slack и еще не знает что у него сервер упал а рутовые права на него он не дал никому?
Или менее опытного коллегу который пишет 100500 вопросов о том что ему надо сделать и как?
Да свое время я еще как ценю ибо оно хорошо оплачивается по меркам моего небольшого города, ценю и время других стараясь не дергать их в slack по каждому вопросу а набираю таких вопросов штук 5-10 и после этого детально разбираем каждый.
Звоню в slack если человек свободен (если ты не можешь принимать звонки — будь добр выстави статус не трогать меня 1/2/4/8 часов). Большинство таки этот статус ставят и он блокирует автоматом уведомления о новых сообщениях и блокирует все входящие звонки.
Как вы ловко записали людей которым тяжело воспринимать много текстовой информации в категорию альтернативно-одаренных.
Но предполагаю что такое деление не совсем корректно, так как нет четкого разделения — скорее довольно большая градация. Например куда отнести меня — человека у которого зрение не 100% зрение, но и не настолько плохое чтобы носить очки. Однако на большем объеме текста глаза начинают уставать.
Еще есть разные типы людей — кто-то хорошо обрабатывает текстовую информацию. Кто-то звуковую, некоторые же видео-информацию, а есть и индивиды которые хорошо обучаются только при передачи информацию в живую персонально.
Еще не будем забывать о том что текстовая передача информации в сети как таковая (а до этого в книжном формате) была обусловлена в первую очередь дороговизной либо невозможностью передачи информации в ином варианте. (До сих пор помню ламповые звуки dialup и выключенные изображения в браузере, и загрузку картинки 20 минут). Отцы же вспомнят особенности проявки пленки для которой нужна чуть ли не целая лаборатория или хотя-бы куча реактивов и большой шкаф.
Сейчас же передача информации в виде аудио и видео формате стала проще текстовой передачи и возможно в некоторых случая и дешевле (время на набор текста, вычитка, коррекция, локализация, вставка поясняющих изображений). Так что естественно что визуальные и аудио форматы во многих сферах вытесняют и вытеснили текст.
Так что не нужно удивляться тому факту что на ТЕКСТОВУЮ RPG вроде GodVille было и есть отличное подробное текстовое описание. На 2D аркады вроде "Косморейнджеров" немного текста и куча скринов а на современные игры Let's Play на YouTube/Twitch.
Плюс наглядность и простота информации в таких форматах действительно более доступна. (Например мне иногда проще просмотреть BPMN диаграмму чем лезть в код и пытаться вспомнить как и что там работает в том модуле который 2 года собирал пыль)
Лично сам наоборот предпочитаю созвоны, если нужно что-то уточнить по задаче то у тебя выбор — писать несколько портянок текста чтобы человек понял сперва контекст потом сам вопрос. Если человек не понял вопрос — опять начинаем сначала а после еще и уточнение.
Плюс если вопрос нужно решить вот прям сейчас — то лучше подойти лично к человеку если вы в одно офисе, если нет — то одни звонок и вопрос решен.
То что заняло минут 30 — 60 занимает 5-15 минут. Так как при звонке явно инициируется коммуникация которую сложно прервать.
С текстом человек может прочитать сообщение и дальше заниматься своими делами, и может быть потом он о нем вспомнит и ответит. Но чаще всего — игнор.
И да я разработчик и да я интроверт и в принципе против любых излишних коммуникаций в любом виде.
Тут думаю важно понимать что разрабатываем, если лендинг или интернет магазин — то действительно на кой нам детальная спецификация проекта.
Точнее спецификация есть — это выписка из брифа с клиентом которая по сути и тз и спецификация.
Другое дело если мы делаем какую либо небольшую информационную систему. Тут уже нужны спецификации — но не обязательно делать их на всю систему — достаточно на критичные модули. Остальное на салфетке и скрины салфетки в систему документации.
Если же нам нужна отказоустойчивая, масштабируемая, инфраструктурная и стабильная система — вроде тех что запускают ракеты/управляют самолетами, кораблями, поездами, линиями связи/медицинская система.
Тут уже полу-мерами не обойтись — ВСЯ система должна быть предварительно смоделирована от веб-портала до последнего микроконтроллера в датчике давления, ВСЕ реализации должны соответствовать спецификации чтобы дать гарантию этого — ВСЕ части системы должны быть обмазаны тоннами авто-тестов, защитным программированием и документацией.
В противном случае — получим кучу трупов, миллиарды баксов убытков и громкое судебное дело с несколькими пожизненными сроками.
Ага и еще при скролле некоторые сайты не совсем корректно её понимают и начинается веселье!
В принципе справедливо, но лучше все таки поместить эти записи в какую либо систему документации.
А так да, можно построить целую систему на бумаге но её еще нужно и реализовать, в итоге получается двойная работа, плюс при реализации всегда всплывают нюансы не учтенные в основной модели и нужно будет опять обновлять модель.
Можно создать систему которая на основе модели уже генерирует готовый софт. Правда из всех похожих систем я видел только OpenESB и Camunda Workflow Engine.
Первый имеет свой UI для создания модели а вторая использует BPMN и DMN.
Оно даже как-то работает но вот ресурсов на поддержку всего этого добра уходит знатное количество.
Есть бредовая идея взять все эти XML подобные аннотации от UML до WSDL и реализовать их в виде новой молодежной json-schema, дать на все это редактор который позволит накидывать эти схемы + вертеть их с каких хочешь ракурсов.
json-schema-hub который будет их хранить и несколько библиотек (автоматическая генерация структур, автоматическая интеграция) для кучи языков.
В итоге у нас буду в одном месте
Успешный ещё как приносит, вот только результат данного решения виден ой в какой долгосрочной перспективе (3-5) лет. Так что многие руководители по ошибке относят его в квадрат "не срочное"|"важное" или даже "не важное".
И вот проходит эти пять лет и продукт вообще не куда не может двигаться, так как носители знания по проекту разбежалась так как уже замучил этот проект. Новые люди сбегают сразу после испытательного периода, старая команда постепенно тоже бежит с тонущего корабля.
В итоге у бизнеса остается три варианта — остановить развитие проекта и ждать пока первый конкурент выкинет их из рынка, выкинуть все что уже есть и начать заново, либо мучить труп нанимая персонал в 1.5-2 раза завышенной вилке.
Если у бизнеса осталась хорошая подушка финансов — то еще есть шанс выплыть. И вот тогда бизнес начинает понимать о важность рефакторинга и больше никогда не забывает.
Хорошо хоть кто-то пытается разобраться в вопросе технологического хаоса для того чтобы навести порядок.
В современном it мире очень много практики и довольно мало науки к сожалению.
Исследуя код и документацию мы может ответь на вопрос как сделана та или иная технология. Но как только поднимаешь вопрос почему это сделано так, а не иначе и есть ли обоснованная причина именно такой реализации — то в большинстве случаев это либо "сделали как получилось" либо "все так делают и мы так делаем" лишь некоторые проекты имеют под собой какой либо фундамент в виде исследований или хотя-бы нескольких итераций разработки и тестов которые доказывает что текущая реализация более-менее оптимальна.
Из за того что нет конкретного подхода в реализации то объяснить решение довольно проблемно — проще навесить ярлык в виде CloudComputing, BigData, AI,
BlohchainBlockchain и тп.Про стажерку и аутсорсера действительно довольно частая ситуация.
В моем городе я знаю только двух девушек разработчиц которые действительно могут самостоятельно разрабатывать софт, причем обе на Spring.
А такие хитрые заразы обычно начинают понимать что лучше идти в Маркетинг,PM или на худой конец HR.
Ну если процесс сборки очень хитрый с кастомными образами, кучей скриптов — то почему бы и нет, но ping + db так собирать это по моему перебор немного...
эмм забавно конечно, но что мешает добавить все эти команды как alias в .bashrc / .zshrc?
В этом случае даже не нужно make писать. Если проектов много можно даже и так:
Знавал я и людей которые умудрялись такое проделывать, проказники.
Вот есть инфоцигане, есть "эффективные менеджеры" а есть и техноцигане.
В общем пара таких "разработчиков". Один на java JavaEE другой на Delphi быстро за день-два пилили интерфейс софтины с кнопочками и парой обработчиков, устраивали демо и продавали фасад программы за пол ляма-лям рублей и потом в течени месяца абы как хреначили mvp которое собственно продали и самое смешное — серьезные компании таки покупали эту #!&$#...
Некоторые так говорят вообще про все js фремворки разом =)
Как по моему. Если это упрощает работу, улучшает стабильность и при этом кушает не сильно много — то почему бы и нет.
А если еще и state-tree прикрутить то вообще сказка
https://github.com/mobxjs/mobx-state-tree
В итоге код вообще становиться похожим на Vuex только в React
Единственное что может Vuex но не может нормально mobx-state-tree это нормальный вызов одних action из других. Но эта фича скорее костыль...
Обновляю браузер как и все остальное — полу-автоматом