учить людей которые пришли с улицы это нормально. Интриги это издержки коллективной работы. Не повезло вам с людьми, но это именно люди, а не специфика профессии.
Аналитик это человек который формализует бизнес требования, дополняет бизнес требования не функциональными требованиями (требования к качеству и характеристикам).
А вот всё остальное про чтение кода, чтение логов, просчёт последствий изменений в бэкэнде на фронтэнд, и прочая прочая это не аналитик. Это архитектор если по технической части, UX/UI дизайнер если по видимой части работы программного продукта и прочие люди которые тоже нужны и которые тоже имеют свои участки ответственности.
Аналитик это не тот кто знает всё и может во всё разобраться. Всё про систему на троих знают: владелец продукта, архитектор, админ отвечающий за эксплуатацию (настройка окружения, выкатка, мониторинг текущий метрик, обеспечение стабильного функционирования).
Не понимаю почему возможная храмота с QA, приведёт к проблемам «как в коммуникации с заказчиками, так и с дизайном решений»?
QA в современном контексте CI/CD стало проявлять не больше 5-ти лет назад. До этог окк люди работали? Приёмочное тестирование без тестов не бывает? или вы ни где кроме «Яндекса» не работали?
Человек умеет писать программные продукты, был фулл-стеком это не значит заменять бизнес аналитиков и менеджеров проекта в купе с менеджерами по продажам. Это значит владеть полным стеком технологий для производства ПО.
Про дизайн решений это вообще за гранью… если проекты у человека без автоматизированного тестирования спокойно обходятся, значит у него всё плохо с архитектурой? Нет, просто не надо тратить время на вещи без которых можно обойтись. Это повышает эффективность.
С MVP у автора всё хорошо: две недели согласовывал ТЗ, за полтора месяца запилил, то есть успешно справился с реализацией MVP, или автор что то провалил?
Живу за МКАДом конечно, но не считаю Екатеринбург периферией, тем не менее с работой и технологиями у меня такой же зоопарк (резюме).
Но это не потому что жизнь такая, а потому что я такой, мне не интересно заниматься ширпотребом, клепать сайтики, или сидеть на поддержке внутренних инф систем предприятия, я всегда нахожу приключений в стартапах созданных вчера, или в маленьких фирмочках со своей долей на рынке не самых обычных услуг.
Не называю это выживанием, называю это «моя весёлая жизнь». Мне нравиться.
Подозреваю что автору тоже, иначе бы он с этим что то бы уже сделал.
Спасибо за серию статей, получились хорошие руководства.
отдельные моменты улыбнули:
Мы вышли из этой ситуации, зашив количество проектов и сроки их сдачи в KPI менеджера и разработчика. Так менедджер всеми силами старается контролировать разработчиков, чтобы те не превышали свои сроки по задачам и сдавали их вовремя.
Менеджеры когда то не наседали? по моему опыту руководители всегда хотят получить вчера, то что им пришло в голову сегодня. Мне исполнителя жалко, он и раньше не знал как сделать работу что бы не потерять в качестве, а теперь вы его ещё и с секундомером у него над душой стоите. Хотя если работа типовая, то это наверное правильная практика.
Совсем другое дело что с вводом лимитов на «операции» и наглядной демонстрацией истечения сроков — исполнители могут наглядно понимать что уже нет времени копаться в нюансах и пора форсировать работу. Это плюс.
Мы видим, кто постоянно опаздывает, а кто приходит вовремя.
а тех кто постоянно задерживается? Или после часа X охрана всех выгоняет?
Не знаю зачем ставить минуса за такие статьи, не считаю что статья прямо какую то ересь пропагандирует.
Но в статье однозначно не хватает подробностей. Автор написал её для себя, человеку не знакомому с особенностями его системы и задачами которые она решает, непонятно ни чего.
В статье есть ответы на вопрос «как?», но не понятно «зачем?».
Если разговор про архитектуру то надо схемку с частями системы, стрелки потоков управления или данных, так понятно будет о чём речь.
Надеюсь эти замечанию помогут автору писать статьи более познавательные и информативные именно для читателей. Писать для себя мне кажется можно в своём блоге, на Хабре читатели не оценят.
спасибо за статью, вполне адекватный выбор великов, по остальному не скажу (часы, наушники), не фанат.
Сам знакомым девочкам регулярно велики подбираю, получаются такие же варианты как в статье.
В статье приятные рассуждения.
По мультистековости есть обычная проблема человеческого мышления, человек ищет решения для здесь и сейчас, автор пишет о том, что первым делом ищут того кто решит все проблемы в одну каску. И с этим ни чего не поделать, всегда люди ищут решение которое быстро и полностью, поэтому недооценённость будет хронической, поэтому для бабок надо быть спецом в одной области, а лучше «дуал»-стеком, для разработки по феншую надо быть мультиком.
Фишка то в том что дуалов ищут люди в разработке ни бум бум, и лапшу на уши им можно вешать бесконечно долго, это я к тому что не надо загоняться тем что если ты дуал то ты вечный мидл, работодателю и так сойдёт.
Пункт 1 не для всех, мало встречал людей которые готовы принять реалистичные сроки, всё больше в сказки верят, обижаются, когда жизнь ставит их перед фактом.
Пункт 4 бомбический :)
На моём опыте два раза искал фронта, и оба раза неудачно. Проекты в итоге дальше альфы бэкэнда не ушли.
Видимо пора осваивать фронт энд :)
проблема микросервисов только в инфраструктуре, если есть готовое решение для мониторинга, выкладки, распределения нагрузки, обработки отказов, то почему нет?
istio — что то такое обещает.
Но на самом деле до всяких микросервисов, надо формализовать бизнес процессы и уже их растаскивать по модулям и сервисам или дробить до микросервисов.
trawl, app/Provider/AppProvider.php — такую портянку теперь обязательно писать?
Прекрасно что ребята повыкидывали всё на свете из фреймворка, так что даже не понятно, а что там вообще осталось, но вот такой бойлер плейт огорчает.
Добавлена фабрика для создания экземпляра приложения;
наверное это хорошо для гибкости, только подталкивает к созданию многофункциональных комбайнов, теперь можно делать два в одном, три в одном и так далее, только зачем? может быть просто сделать два или три отдельных приложения которые будут шарить одни и те же либы (пакеты, зависимости)?
С другой стороны если делать тестирование на коленке, то наверное удобно, на одном и том же сервере можно прогнать один и тот же тест на двух немного разных реализациях.
Обработчик запроса приложения теперь принимает только объект запроса (в старой версии принимал объекты запроса и ответа).
Раньше можно было на каждом этапе что то в ответ добавить, но видимо это ни кому не нужно.
Лично мне не понятно зачем всё это было сделано. Фреймворк это всё такие готовый набор инструментов и какие то направляющие для работы, а теперь Slim это что угодно и как угодно.
Slim PHP — собери свой набор!
Slim был микрофреймворком, на следующем этапе он проскочил нанофреймворки и просто растворился — перестал быть фреймворком — ни каких рамок, творчество без границ.
Автор прав, но прав только для бедных компаний, или компаний где не на чем заработать, поэтому ищут на чём сэкономить, например на заказной разработке ПО.
Работал в фирме которая обслуживала ERP и какие то доработки нам заказывали только при крайней нужде, просто потому что если что то заказать, то пострадают финансовые показатели, а для начальников от этих циферок зависела их з/п. Вот так банально. Такая коррупция, лишь бы показать хорошую отчётность.
Кроме того можно понять логику начальников: люди есть — пусть работают (абонентский и финансовый отделы, бухгалтерия), нет смысла ускорять их работу, если они свою работу сделают быстрей, что же они будут делать? сидеть без дела?
Всё от людей зависит, ERP это инструмент как и все другое, инструментом надо работать, и не только работать, но ещё и уметь работать.
есть государстквенный сервис «Российская государственная инициатива» для инициатив на уровне РФ, есть паблике в ВК для решения проблем на районе, городские порталы и всё такое. У нас во дворе есть чат в вотс аппе. То есть инструментов хватает, но у людей нет мотивации вопросы поднимать и решать.
Вопрос поднять конечно можно, но ни кто не будет поднимать его если не будет решения, а самим палец о палец ударить людям лень. Заявляю это как старший по дому с 5+ лет стажа. У двора есть проблемы, а желающих их решать — нет. Все проблемы которые мне удавалось разрулить были решены моими силами или силами других одиночек, которых эта беда задела за живое.
Личная инициатива есть, а общественной нет.
Моя хата с краю — вот девис современного россиянина.
Работаю по удалёнке, у нас все 5 сотрудников на удалёнке, но мы всегда на связи, в Скайпе можно расшарить экран и это очень выручает, для работы большего и не надо.
У меня раньше был опыт работы из дома, и я в курсе что семья ни когда не даст тебе спокойно поработать, поэтому на собеседовании я сразу попросил офис, и мне его оплачивают, я там всё обставил как мне надо и прекрасно мне там работается, если надо могу прямо в офисе поспать, или пойти погулять по соседним паркам, ни кого не парит моё отсутствие, офис доступен круглосуточно, прихожу к 13, ухожу когда в 20, когда в 24 часа, зависит от работы, сделал дело — гуляй смело!
Мне норм.
Я привык углубиться в одну задачу и работать над ней до победы, поэтому совмещение с ещё какими то проектами это не для меня, делать это в ущерб основной работе считаю не достойным.
Конечно если мне надо по делам куда то сгонять, я спокойно свалю. Преимущества удалёнки в свободном графике, но таски в трекере это не отменяет :)
А вот всё остальное про чтение кода, чтение логов, просчёт последствий изменений в бэкэнде на фронтэнд, и прочая прочая это не аналитик. Это архитектор если по технической части, UX/UI дизайнер если по видимой части работы программного продукта и прочие люди которые тоже нужны и которые тоже имеют свои участки ответственности.
Аналитик это не тот кто знает всё и может во всё разобраться. Всё про систему на троих знают: владелец продукта, архитектор, админ отвечающий за эксплуатацию (настройка окружения, выкатка, мониторинг текущий метрик, обеспечение стабильного функционирования).
QA в современном контексте CI/CD стало проявлять не больше 5-ти лет назад. До этог окк люди работали? Приёмочное тестирование без тестов не бывает? или вы ни где кроме «Яндекса» не работали?
Человек умеет писать программные продукты, был фулл-стеком это не значит заменять бизнес аналитиков и менеджеров проекта в купе с менеджерами по продажам. Это значит владеть полным стеком технологий для производства ПО.
Про дизайн решений это вообще за гранью… если проекты у человека без автоматизированного тестирования спокойно обходятся, значит у него всё плохо с архитектурой? Нет, просто не надо тратить время на вещи без которых можно обойтись. Это повышает эффективность.
С MVP у автора всё хорошо: две недели согласовывал ТЗ, за полтора месяца запилил, то есть успешно справился с реализацией MVP, или автор что то провалил?
Но это не потому что жизнь такая, а потому что я такой, мне не интересно заниматься ширпотребом, клепать сайтики, или сидеть на поддержке внутренних инф систем предприятия, я всегда нахожу приключений в стартапах созданных вчера, или в маленьких фирмочках со своей долей на рынке не самых обычных услуг.
Не называю это выживанием, называю это «моя весёлая жизнь». Мне нравиться.
Подозреваю что автору тоже, иначе бы он с этим что то бы уже сделал.
отдельные моменты улыбнули:
Менеджеры когда то не наседали? по моему опыту руководители всегда хотят получить вчера, то что им пришло в голову сегодня. Мне исполнителя жалко, он и раньше не знал как сделать работу что бы не потерять в качестве, а теперь вы его ещё и с секундомером у него над душой стоите. Хотя если работа типовая, то это наверное правильная практика.
Совсем другое дело что с вводом лимитов на «операции» и наглядной демонстрацией истечения сроков — исполнители могут наглядно понимать что уже нет времени копаться в нюансах и пора форсировать работу. Это плюс.
а тех кто постоянно задерживается? Или после часа X охрана всех выгоняет?
Но в статье однозначно не хватает подробностей. Автор написал её для себя, человеку не знакомому с особенностями его системы и задачами которые она решает, непонятно ни чего.
В статье есть ответы на вопрос «как?», но не понятно «зачем?».
Если разговор про архитектуру то надо схемку с частями системы, стрелки потоков управления или данных, так понятно будет о чём речь.
Надеюсь эти замечанию помогут автору писать статьи более познавательные и информативные именно для читателей. Писать для себя мне кажется можно в своём блоге, на Хабре читатели не оценят.
Сам знакомым девочкам регулярно велики подбираю, получаются такие же варианты как в статье.
По мультистековости есть обычная проблема человеческого мышления, человек ищет решения для здесь и сейчас, автор пишет о том, что первым делом ищут того кто решит все проблемы в одну каску. И с этим ни чего не поделать, всегда люди ищут решение которое быстро и полностью, поэтому недооценённость будет хронической, поэтому для бабок надо быть спецом в одной области, а лучше «дуал»-стеком, для разработки по феншую надо быть мультиком.
Фишка то в том что дуалов ищут люди в разработке ни бум бум, и лапшу на уши им можно вешать бесконечно долго, это я к тому что не надо загоняться тем что если ты дуал то ты вечный мидл, работодателю и так сойдёт.
Пункт 4 бомбический :)
На моём опыте два раза искал фронта, и оба раза неудачно. Проекты в итоге дальше альфы бэкэнда не ушли.
Видимо пора осваивать фронт энд :)
istio — что то такое обещает.
Но на самом деле до всяких микросервисов, надо формализовать бизнес процессы и уже их растаскивать по модулям и сервисам или дробить до микросервисов.
Прекрасно что ребята повыкидывали всё на свете из фреймворка, так что даже не понятно, а что там вообще осталось, но вот такой бойлер плейт огорчает.
наверное это хорошо для гибкости, только подталкивает к созданию многофункциональных комбайнов, теперь можно делать два в одном, три в одном и так далее, только зачем? может быть просто сделать два или три отдельных приложения которые будут шарить одни и те же либы (пакеты, зависимости)?
С другой стороны если делать тестирование на коленке, то наверное удобно, на одном и том же сервере можно прогнать один и тот же тест на двух немного разных реализациях.
Раньше можно было на каждом этапе что то в ответ добавить, но видимо это ни кому не нужно.
Лично мне не понятно зачем всё это было сделано. Фреймворк это всё такие готовый набор инструментов и какие то направляющие для работы, а теперь Slim это что угодно и как угодно.
Slim PHP — собери свой набор!
Slim был микрофреймворком, на следующем этапе он проскочил нанофреймворки и просто растворился — перестал быть фреймворком — ни каких рамок, творчество без границ.
Работал в фирме которая обслуживала ERP и какие то доработки нам заказывали только при крайней нужде, просто потому что если что то заказать, то пострадают финансовые показатели, а для начальников от этих циферок зависела их з/п. Вот так банально. Такая коррупция, лишь бы показать хорошую отчётность.
Кроме того можно понять логику начальников: люди есть — пусть работают (абонентский и финансовый отделы, бухгалтерия), нет смысла ускорять их работу, если они свою работу сделают быстрей, что же они будут делать? сидеть без дела?
Всё от людей зависит, ERP это инструмент как и все другое, инструментом надо работать, и не только работать, но ещё и уметь работать.
Вопрос поднять конечно можно, но ни кто не будет поднимать его если не будет решения, а самим палец о палец ударить людям лень. Заявляю это как старший по дому с 5+ лет стажа. У двора есть проблемы, а желающих их решать — нет. Все проблемы которые мне удавалось разрулить были решены моими силами или силами других одиночек, которых эта беда задела за живое.
Личная инициатива есть, а общественной нет.
Моя хата с краю — вот девис современного россиянина.
У меня раньше был опыт работы из дома, и я в курсе что семья ни когда не даст тебе спокойно поработать, поэтому на собеседовании я сразу попросил офис, и мне его оплачивают, я там всё обставил как мне надо и прекрасно мне там работается, если надо могу прямо в офисе поспать, или пойти погулять по соседним паркам, ни кого не парит моё отсутствие, офис доступен круглосуточно, прихожу к 13, ухожу когда в 20, когда в 24 часа, зависит от работы, сделал дело — гуляй смело!
Мне норм.
Я привык углубиться в одну задачу и работать над ней до победы, поэтому совмещение с ещё какими то проектами это не для меня, делать это в ущерб основной работе считаю не достойным.
Конечно если мне надо по делам куда то сгонять, я спокойно свалю. Преимущества удалёнки в свободном графике, но таски в трекере это не отменяет :)