Koztrofi
Заметки об ИТ проектах
Почему вы упорно путайте агил (запрещено в некоторых организациях) и срам
Агил включает в себя огромный пул методологий: кайдзен, канбан (с 5 столбиками, как и указано в первоисточнике), научная организация труда, теория ограничения систем, лин систем, тойота продакш систем, 6 сигм и ещё много чего интересного
Вы же из раза в раз натягивайте срам на всё до чего можно дотянутся, уже на западе срамо идеологи признают что это карго культ
Совет один: подбирайте методологию исходя из задач, ресурсов, компетенции - нет универсального подхода;)))
Спорная статья, ипотека в половину дохода не такая и жесть как кажется
Ни одной связки
Факт -> следствии -> вывод
Очки сняты не были;)))
Очень по новогоднему:)
Если вы не предлагаете услуги правки резюме, то ваша статья лишь увеличит нагрузку и стоимость подбора
Базовый фильтр вы уже ломаете:)
У всех свои причины, и не все готовы меняться:(
У меня уже побольше:) Приближаюсь к пенсии маленькими но уверенными шашками;)
Курить уже бросил, скоро брошу пить, наверное начну пробовать отказаться от определенной еды:)))
И зарплаты подросли:)
Есть, в основном отчитывается департамент связанный с экологией, надо смотреть на уровне субъекта
Вот вам сайт, не благодарите;)
Мне кажется вы не под ту статью комментарии пишите
Что вы подразумеваете под термином - лемматизация? (я загуглил, теперь у меня сомнения 🧐)
Заказчику и не надо, он же платит, мы адаптируемся, я и написал, дефицит аналитиков;)
Можно и нормальное ТЗ заказчику дать
Слово мне не очень нравится, но назовите его Бизнес архитектура
И уложите туда названия процессов и целей - сами функции будут максимально гибкими и можно через допник
Для нефункциональных сделайте конструктор, да хоть в экселе
- беза
- количество пользователей внутренних
- количество пользователей внешних
- структура развертывания
Уже большую часть снимите
Отдельно конструктор СТП
- чат
- сотрудник (если понятно количество пользователей, то посчитать легко)
- 24/7
И всё пойдёт, если хотите, могу помочь;)
Делегирование самый сложный метод, так необходимо учитывать всё, что вы ниже упомянули:
- квалификацию
- мотивацию
- границы задачи
- определить, кто что не делает
- наполнение ресурсами исполнителя
Если коротенько то так:)
Прикольно, писать об отказе от ТЗ, при этом его писать, но немного в другом виде
То что вы написали «без ТЗ» - это по факту постановка на разработку:)))
- Story (история пользователя)
- cjm (с него лучше начинать, так как это не что иное, как шаги по получению ценности)
- макеты, странно что не указали ux/ui (как раз ux опыт пользователя, ui картинка)
- front back , я бы добавил db и поменял последовательность db(база данных), back, front (при таком подходе у вас story будет состоять из тикитов)
- test отлично
- авторская приемка/демо надо бы добавить
- если душный заказчик, можно тикет Doc добавить
Так что вы работайте по ТЗ, просто по производственному
А проблема в ТЗ с заказчиком не в ТЗ, а в аналитиках и людях, которые не понимают как устроен бизнес:)))
Очень уважительное обращение к клиентам:)))
Может причина в этом;)
И да, супер кофе (который варят) стоит от 300 рублей упаковка грам 150-300 и он супер вкусный
Кофе в кофе местах, который позиционируется как вкусный от 300 рублей не самый вкусный
Но самое удивительное, когда попробуешь тот что сам купил, он в разы вкуснее.
Я жене по утрам варю 2 чашки, она теперь нигде не может кофе пить, иногда соглашается на турецкий (это когда в турке при тебе), упаковки хватит на 1,5 недели
Где тут и есть истина:)))
Очень спорно, насчёт: «… начнем с элементарного, делегирования..» - прям на максималках спорно;)
Раз есть про сотрудников необходимо дополнить и другой стороной
Типы начальников https://dzen.ru/a/YEyFvWyGHwEH1Rkj
Отличное чтиво:)))
Отличная статья, огромное спасибо за труд и понятное разъяснение
Немного про чуваков
https://www.youtube.com/shorts/05LZA9Cwwwo :)
Подход отличный! Но сам факт наличия дизайнерского это очень странно, для продуктовых команд прям на грани (это же то ради чего и пилят фичи)
в Jira надо было попросить добавить Demo или Авторская приемка (по факту название можно подобрать исходя из убеждений команды разработки и принятым ритуалам, во всех фреймоворках есть такой этап:))
Этот этап как раз про проверку достижения целей реализации:)
Я честно пытался выполнить тест по Scrum, и скажу вам прямо, некоторые вопросы были прям явно за рамками https://scrumguides.ru/scrum-guide.html
На мой взгляд это ещё один тревожный сигнал
Выводы делать лучше рекрутеру, я лишь могу зафиксировать аномалию
Подскажите, а вы анализируйте п.2 по эффективности привлечения с разных каналов? Можете подсказать, как автоматизировали?
Много джунов - это надо курсы благодарить:)))
Хотел уточнить, вы наверное обратили внимание на похожесть резюме?
И как вам тестирование на хх от Яндекса?
Было бы интересно прочитать в следующей статье
Открою вам секрет про добавление возрастной планки
Пик рождаемости СССР 1982-1987
При отказе нанимать старше, просто некого будет нанимать:)))
И не забываем о качестве образования, педагоги старались, времена были тяжелые
Не знал что проекты по внедрению 1С могут провалится
Когда руководил компаниями (наёмным СЕО), два раза внедрял и всё было норм
На сколько помню, из коробки даже УПП (были проблемы с закрытием периода) нормально настраивалась:)))
Если верить сурам гайду, то нет
Я выше привёл ссылку
А у вас что то своё:) Главное что оно работает, а как называется наверное не так важно
Есть отличная статья о сравнении Agile и Научной организации труда
Рекомендую, текст может дать вам новый инструментарий на сайте e-library.ru его можно найти
Там много чего не написано, о чём говорят «неофиты» :)))
Согласен,
И с точки зрения Scrum Guide это не верно:)))
Scrum Master не поддержит:)))
Спорное утверждение
- качественное управление направлено на решение всего комплекса задач и понимание рисков
- при качественном управлении нет смысла ежедневно сверяться
- при качественном управлении каждый участник понимает границы ответственности
- при качественном управлении участник вовлечен в чужие активности на сколько, на сколько он сам хочет
При данных условиях проекты и продукты становятся отличными и приносят максимум выгод:)
Scrum - это термин из регби, где задача, занести мяч за границу у противоположной команды. И ключевая задача в регби, это пройти ещё чуть чуть
В проектах и продуктах ключевая задача получить выгоду, маленькие шажки которые не дают выгод, никому не интересны:)
Согласен, что он работает
Какой ценой?
Scrum прячет низкое качество управления, в связи с этим популярен
И кстати самый распиаренный легкий фреймворк
ТЗ - это защита от странных заказчиков и тех о ком сделали мультик Жадный богач (из 1 шкуры 7 шапок:))))
И в манифесте нет утверждение что документация не нужна https://agilemanifesto.org/iso/ru/manifesto.html
там лишь указано: Работающий продукт важнее исчерпывающей документации
Смотря какую задачу решаете, если задача понятна и с понятными границами принятия решения, опытный даст больше, если же границы принятия решения размыты и задача может меняться в процессе (специфика малого бизнеса:)) то лучше создавать своих