Вот что лично меня всегда настораживает в статьях про софтскиллы — это «давайте сделаем вид, что все всё понимают». Я вот не понимаю.
На данный момент вариантов классификаций и перечней гибких навыков очень много, поэтому пока не будем акцентировать внимание на конкретных умениях. Я буду говорить о софт-скиллах в обобщенном понимании, и не обязательно все из них вы тоже считаете таковыми.
Что за обобщённое понимание? Что такое, например, «умение слушать», может ли ему обучиться глухонемой с рождения?
С хардскиллами всё более-менее понятно: навык — умение реализовать систему А с заданными критериями качества. Очевидно, какой результат, какие параметры оценки, можно прикинуть способы развития навыка.
С софтскиллами одни вопросы: навык — рефлексия (так же качает умение принимать решения и развита у интровертов). Какой результат, какие параметры оценки, как развивать навык?
Если есть статья с полным разбором что есть каждый конкретный софтскилл, где он заканчивается, как измеряется и развивается, как они классифицируются и почему всё именно так — скиньте, пожалуйста. До тех пор остаётся всё же считать что софт-скиллы — это то, о чем мы почти ничего не знаем (но почему-то очень любим порассуждать).
to feel yourself good = чувствовать себя хорошо (правильно сказать to feel good).
Согласно башоргу, в этом примере можно и в куда более интересную ситуацию попасть.
18+
Начальник как-то на митинге поведал:
— Был я в командировке в Америке. И вот в один из дней надо на работу, а я чувствовал себя хреново… Короче, звоню и девочке на телефоне говорю на английском, что мне хреново и я мол на работу не пойду. Ну она смеется минуты три, потом похихикивая говорит окей. А сказал я следуюющее: «I feel myself bad, so I won't come today». Ну вроде с русского дословно — че хотел сказать то и сказал, че она смеется? Оказывается, что feel myself — означает мастурбацию. Ага — ей звонить сотрудник и говорит: «Вы знаете, я сегодня чего-то хуево подрачил, я на работу не пойду.»
Что сейчас происходит? Ну, в принципе да, всё верно.
Аргументы «нерабочих» и контраргументы к ним. Да в принципе тоже верно.
Ни с чем по отдельности не поспоришь, а со статьёй всё равно не согласен.
Надо просто заменить «коронавирус» на «указ президента», «кризис», «падение рынков», «фукусима», «нашествие рептилоидов».
Да, наступают сложные времена и никто не знает сколько они продлятся. Да, надо затянуть пояса и потерпеть. Да, есть риск остаться без работы, внезапной смерти или извержения пивного вулкана. Это вполне обычная и типичная ситуация, хоть и куда менее приятная.
Именно поэтому надо несмотря на происходящее действовать, как и раньше: работать вне зависимости от разговоров по ящику, в рамках законодательства и уходить от плохих работодателей по возможности.
Работайте хоть на кого-то пока можете — тоже, в своём роде, паника.
Или, как это часто бывает, спросили в лицензионном соглашении (вы ведь читаете лицензионные соглашения к драйверам и службе печати или приложению для сканирования?).
Я не оправдываю излишний сбор данных, на который сейчас начали обращать внимание и пользователи, и правительства, и кто только не. Я высказываю гипотезу почему он стал таким, каким является.
Зачастую продаются уже обжаренные зёрна.
Если же мы будем отделять процесс приготовления кофе от операции «взять», то получится как в старой цитате про взятие интеграла методом Симпсона:
#394402
Tigger
Взятие интеграла методом Симпсона
Tigger
Я так понимаю, это вот как:
1. Подойти
2. Взять.
Да нет, просто есть компании, которым нужен специалист поддержки, девопс, аналитик, архитектор, тестировщик, дизайнер, UX-проектировщик и техпис, всё это не считая разработчиков и управленцев.
А есть те, которым нужен эникейщик, чтоб умел всё и подешевле. Как умеет — не так уж и важно, всё равно никто не разбирается.
Можно, но попробуй докажи энному количеству аудиторов, что вы _всего-лишь_ шифруете файл, а не добавляете в него бэкдоры на каждом из этапов. Даже двойное шифрование — задача не из лёгких в этом плане.
И это всё не говоря уж о том, что надзорные органы могут потребовать использовать только их шифрование.
Решил ПМ. Почему — в идеале надо у него спрашивать.
Как видится мне: нам необходимо добавить новый функционал, предполагающий новый подход работы с системой. Для того, чтобы это сделать, необходимо его аккуратно положить на старые рельсы и архитектуру как минимум ничего не сломав, как максимум по пути разгрести частично имеющийся техдолг (система осталась в наследство от другой группы разработки и создавалась как прототип). Я не знаю имеющихся архитектурных ограничений и не в моей компетенции определять детали реализации, этим занимаются разработчики, и сроки или глубину декомпозиции задач, этим занимается ПМ. Таким образом, на момент до обсуждения (в котором оценка трудозатрат лишь малая часть), информация и экспертиза размазана по отдельным лицам в команде, после — имеется у всей команды.
Наверное, в практике или теории проектного управления есть рекомендации когда необходимо проводить такие обсуждения, что на них должно быть и т.д. Я же могу оттолкнуться только от своей оценки по количеству затрагиваемых пользовательских сценариев и практики работы команды. С этой точки зрения фича достаточно большая, т.к. затрагивает минимум 5 сценариев (это так, с ходу) и на реализацию сравнимого функционала у команды (два разработчика, тестировщик и аналитик) ушло два месяца в прошлый раз.
Совместная оценка трудозатрат с разработчиками на основании выявленных требований и известном техдолге. Например, у текущей фичи оценки были в 2-4 месяца, пока укладываемся и, похоже, уложимся. Могу разработчика призвать, прокомментирует :)
Менеджер проекта обычно. Но можем и силами команды спокойно всё организовать. Главное отделить встречу про техническую реализацию (проводимую без заказчика) от встречи про потребности и видение (такие встречи и с командой, и с заказчиком иногда проводятся для обеспечения взаимопонимания, контроля работы аналитика и успокоения заказчика).
Хотел подробно, но после третьей стёртой простыни понял что такое лучше в личку :)
1. Если требования готовить заранее, они устаревают или замыливается глаз. Поэтому детализацию необходимо повышать итерационно.
2. Можно проводить ревью требований, но к такому не готов ни один участник процесса: у заказчика нет времени, разработчикам необходимо отдельно сесть подумать, ПМ/другой аналитик имеет ещё достаточно много дел. В нашей команде если грядёт большая фича мы после выявления достаточно полного набора требований садимся и обсуждаем реализацию.
3. Если готовить требования по мере востребованности (вечером на митинге обсудили что будет сделано завтра), обеспечивая актуальность, получится очень много TBD пунктов.
Краткий вывод: полное и окончательное ТЗ физически невозможно на сложную систему. Даже одноатомные молекулы и те с допусками. Метрологией, ITIL, процессами управления разработки или иной борьбой со сложностью можно найти нужный баланс между полнотой и оперативностью уточнения.
Вывод: требованиями необходимо управлять так же, как бэклогом, баглистом, сроками и прочим. Команда может прожить без компетентного архитектора/аналитика/тестера/etc. Но зачем?
У меня есть ответ на противоположный.
Джава не подходит для браузеров? Оно работает? Работает. Специалисты есть? Есть. Бизнес потребность закрыл? Закрыл. Скорость? Мы тут не спутники запускаем.
JS для хайлоада? Его у нас нет. Позаботиться о будущем? Ну так давайте сразу представительства ООО «Рога и Копыта» по всему миру откроем, документацию ко всему напишем и лолакизуем всё хотя бы языков на 50, только платить за это будете из зарплаты.
Если вдруг компания вырастет до неподъёмного технического долга — то это будет полной ошибкой и некомпетентностью управленцев в области управления риска.
А на Ваш вопрос ответ, поэтому, может звучать так:
Выбор нормального инструментария, покрытие тестами, хорошая инфраструктура — это не совсем про прибыль и расходы. Это про амортизацию и накапливающийся износ. Как завод не хочет остаться внезапно без станков, так и компании должно быть страшно остаться с умершим сервером и невозможностью масштабирования. Если бизнес хочет оказаться в такой ситуации или планирует прожить меньше, чем износ достигнет критической отметки — пожалуйста.
(Всплыла забавная аналогия про российский аджайл и проектную работы: это как купить станок, поубивать его, и продать «новый, почти не использованный, не битый» дальше)
Манера снимать фильмы по мотивам собственного бреда, оставляя от книги только название распространена повсеместно, возьмите тот же роман Сталкер и одноименный фильм.
Но есть же записки самих АБС (блок Киносценарии), в которых они описывают свою работу над сценарием фильма, по мотивам собственной книги. Это отдельное произведение с достаточно непростой судьбой создания. Считать этот фильм экранизацией «Пикника» в наше просвещнное время немного опрометчиво.
Хм. То есть, если ей руководствоваться, то гитхаб ждёт развитие и уход в only-Microsoft фичи.
А если не руководствоваться и смотреть на пример скайпа, то гитхаб ждёт скатывание в непонятно во что, так как все силы брошены на «github for business»?
Я даже не знаю, какой из этих двух стульев удобнее.
Вот специально сейчас открыл своё текущее расписание. Технологии обработки информации, Надёжность и качество информационных систем, Моделирование систем и процессов, Информационная безопасность и защита информации, Электротехника, электроника и схемотехника ЭВМ. Кафедра электротехники и информационно-измерительных систем, Институт Информационных Технологий и Автоматизированных Систем Управления.
Сможете ли вы по этой информации (учебный план с трудом, но ищется, документы минобра ищутся достаточно легко) восстановить что мы собственно изучаем?
Мне кажется, если оставить в предмете «Философия» краткий курс истории философии и более подробный курс эпистемологии в соотношении 1:2, у большинства людей пропадёт вопрос, зачем им философия.
Из минусов — отсутствие e2e шифрования и частного использования для коммуникаций any2any (т.к. корпоративный мессенджер)
Последняя причина, скорее всего, и послужила причиной использования прослойки (выполненную, скорее всего, в виде отдельного плагина для Teams).
Что за обобщённое понимание? Что такое, например, «умение слушать», может ли ему обучиться глухонемой с рождения?
С хардскиллами всё более-менее понятно: навык — умение реализовать систему А с заданными критериями качества. Очевидно, какой результат, какие параметры оценки, можно прикинуть способы развития навыка.
С софтскиллами одни вопросы: навык — рефлексия (так же качает умение принимать решения и развита у интровертов). Какой результат, какие параметры оценки, как развивать навык?
Если есть статья с полным разбором что есть каждый конкретный софтскилл, где он заканчивается, как измеряется и развивается, как они классифицируются и почему всё именно так — скиньте, пожалуйста. До тех пор остаётся всё же считать что софт-скиллы — это то, о чем мы почти ничего не знаем (но почему-то очень любим порассуждать).
Согласно башоргу, в этом примере можно и в куда более интересную ситуацию попасть.
— Был я в командировке в Америке. И вот в один из дней надо на работу, а я чувствовал себя хреново… Короче, звоню и девочке на телефоне говорю на английском, что мне хреново и я мол на работу не пойду. Ну она смеется минуты три, потом похихикивая говорит окей. А сказал я следуюющее: «I feel myself bad, so I won't come today». Ну вроде с русского дословно — че хотел сказать то и сказал, че она смеется? Оказывается, что feel myself — означает мастурбацию. Ага — ей звонить сотрудник и говорит: «Вы знаете, я сегодня чего-то хуево подрачил, я на работу не пойду.»
Аргументы «нерабочих» и контраргументы к ним. Да в принципе тоже верно.
Ни с чем по отдельности не поспоришь, а со статьёй всё равно не согласен.
Надо просто заменить «коронавирус» на «указ президента», «кризис», «падение рынков», «фукусима», «нашествие рептилоидов».
Да, наступают сложные времена и никто не знает сколько они продлятся. Да, надо затянуть пояса и потерпеть. Да, есть риск остаться без работы, внезапной смерти или извержения пивного вулкана. Это вполне обычная и типичная ситуация, хоть и куда менее приятная.
Именно поэтому надо несмотря на происходящее действовать, как и раньше: работать вне зависимости от разговоров по ящику, в рамках законодательства и уходить от плохих работодателей по возможности.
Работайте хоть на кого-то пока можете — тоже, в своём роде, паника.
Я не оправдываю излишний сбор данных, на который сейчас начали обращать внимание и пользователи, и правительства, и кто только не. Я высказываю гипотезу почему он стал таким, каким является.
Если же мы будем отделять процесс приготовления кофе от операции «взять», то получится как в старой цитате про взятие интеграла методом Симпсона:
Взятие интеграла методом Симпсона
Tigger
Я так понимаю, это вот как:
1. Подойти
2. Взять.
Время на выпивание кофе = x;
Время на взять и выпить = y + x;
x <= 0.5 (y + x)
Данный критерий очень легко доводится до бесконечности увеличением времени операции «взять кофе».
Не надо было в таком случае вообще кофемашинки ставить, достаточно было одной турки, одной кофемолки и большого количества пакетов с зерновым кофе :)
А есть те, которым нужен эникейщик, чтоб умел всё и подешевле. Как умеет — не так уж и важно, всё равно никто не разбирается.
И это всё не говоря уж о том, что надзорные органы могут потребовать использовать только их шифрование.
Как видится мне: нам необходимо добавить новый функционал, предполагающий новый подход работы с системой. Для того, чтобы это сделать, необходимо его аккуратно положить на старые рельсы и архитектуру как минимум ничего не сломав, как максимум по пути разгрести частично имеющийся техдолг (система осталась в наследство от другой группы разработки и создавалась как прототип). Я не знаю имеющихся архитектурных ограничений и не в моей компетенции определять детали реализации, этим занимаются разработчики, и сроки или глубину декомпозиции задач, этим занимается ПМ. Таким образом, на момент до обсуждения (в котором оценка трудозатрат лишь малая часть), информация и экспертиза размазана по отдельным лицам в команде, после — имеется у всей команды.
Наверное, в практике или теории проектного управления есть рекомендации когда необходимо проводить такие обсуждения, что на них должно быть и т.д. Я же могу оттолкнуться только от своей оценки по количеству затрагиваемых пользовательских сценариев и практики работы команды. С этой точки зрения фича достаточно большая, т.к. затрагивает минимум 5 сценариев (это так, с ходу) и на реализацию сравнимого функционала у команды (два разработчика, тестировщик и аналитик) ушло два месяца в прошлый раз.
Хотел подробно, но после третьей стёртой простыни понял что такое лучше в личку :)
1. Если требования готовить заранее, они устаревают или замыливается глаз. Поэтому детализацию необходимо повышать итерационно.
2. Можно проводить ревью требований, но к такому не готов ни один участник процесса: у заказчика нет времени, разработчикам необходимо отдельно сесть подумать, ПМ/другой аналитик имеет ещё достаточно много дел. В нашей команде если грядёт большая фича мы после выявления достаточно полного набора требований садимся и обсуждаем реализацию.
3. Если готовить требования по мере востребованности (вечером на митинге обсудили что будет сделано завтра), обеспечивая актуальность, получится очень много TBD пунктов.
Краткий вывод: полное и окончательное ТЗ физически невозможно на сложную систему. Даже одноатомные молекулы и те с допусками. Метрологией, ITIL, процессами управления разработки или иной борьбой со сложностью можно найти нужный баланс между полнотой и оперативностью уточнения.
Вывод: требованиями необходимо управлять так же, как бэклогом, баглистом, сроками и прочим. Команда может прожить без компетентного архитектора/аналитика/тестера/etc. Но зачем?
Джава не подходит для браузеров? Оно работает? Работает. Специалисты есть? Есть. Бизнес потребность закрыл? Закрыл. Скорость? Мы тут не спутники запускаем.
JS для хайлоада? Его у нас нет. Позаботиться о будущем? Ну так давайте сразу представительства ООО «Рога и Копыта» по всему миру откроем, документацию ко всему напишем и лолакизуем всё хотя бы языков на 50, только платить за это будете из зарплаты.
Если вдруг компания вырастет до неподъёмного технического долга — то это будет полной ошибкой и некомпетентностью управленцев в области управления риска.
А на Ваш вопрос ответ, поэтому, может звучать так:
Выбор нормального инструментария, покрытие тестами, хорошая инфраструктура — это не совсем про прибыль и расходы. Это про амортизацию и накапливающийся износ. Как завод не хочет остаться внезапно без станков, так и компании должно быть страшно остаться с умершим сервером и невозможностью масштабирования. Если бизнес хочет оказаться в такой ситуации или планирует прожить меньше, чем износ достигнет критической отметки — пожалуйста.
(Всплыла забавная аналогия про российский аджайл и проектную работы: это как купить станок, поубивать его, и продать «новый, почти не использованный, не битый» дальше)
Но есть же записки самих АБС (блок Киносценарии), в которых они описывают свою работу над сценарием фильма, по мотивам собственной книги. Это отдельное произведение с достаточно непростой судьбой создания. Считать этот фильм экранизацией «Пикника» в наше просвещнное время немного опрометчиво.
А если не руководствоваться и смотреть на пример скайпа, то гитхаб ждёт скатывание в непонятно во что, так как все силы брошены на «github for business»?
Я даже не знаю, какой из этих двух стульев удобнее.
Сможете ли вы по этой информации (учебный план с трудом, но ищется, документы минобра ищутся достаточно легко) восстановить что мы собственно изучаем?