Как легко потерять смысл разработки, добавляя “полезности”
Сделаем ещё кнопку, она “точно нужна”
Добавим фильтр, и сортировку, и модалку, ну мало ли
Вот бы выгрузку в Excel, и график, и пуши!
…Проект набирает скорость. Только куда?
В чём проблема? Когда цель — просто сделать больше фичей, а не решить конкретную задачу, продукт начинает разваливаться: интерфейс пухнет, команда тонет в «хотелках», релизы идут в спешке, а люди - даже не замечают большинство этих «удобств»
Парадокс: чем больше фич, тем хуже продукт
Потому что он уже не про ценность, а про “галочки” и “давайте сделаем ещё”.
У фичи должен быть KPI, надо ставить вопрос «а что изменится от нее?». Также их надо подчищать, если старые не используются: «больше ≠ лучше»
Хороший пример: есть множество платных плагинов для Notion, в которых тонна функций. Но пользователям часто нужна была именно интеграция с Гугл таблицами, они не хотели переплачивать за другие возможности плагина.
Один парень заметил это, и сделал элементарный плагин для интеграции Notion с Google Sheets, на чем начал зарабатывать хорошие деньги. Людям не нужно «все и сразу», им нужна качественная точечная фича
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
Почему зависимость от одного специалиста может утопить всю команду. Выглядит как супергерой. На деле — одиночка, от которого зависит всё.
Это «человек-комбайн». Его любят, на него надеются, он незаменим. До тех пор, пока всё не рухнет.
Первый этап
Команда обращается за всем именно к нему: помощь, проверка, советы. Он — живая документация и мозг проекта.
Для бизнеса всё выглядит отлично: «три в одном, да ещё и без лишних затрат».
Второй этап
Постепенно «комбайн» устаёт: таски неинтересные, общения слишком много, помощи просят постоянно.
Он начинает раздражаться, отказывать, “зависимые” замыкаются. Процессы начинают проседать — но пока это незаметно сверху.
Третий этап
Бизнес не замечает проблему, а специалист уже морально ушёл. Проходит немного времени, и вот он увольняется. И…
Судный день
Без него — никто не знает, как деплоить, где что лежит, как починить баг.
Документации нет, у разработчиков паника.
Прод падает. Клиенты жалуются. Команда — в ступоре.
Восстановление занимает недели. А иногда — проект просто не поднимается.
Как не угодить в ловушку?
Раздавайте ответственность. Не сливайте всё на одного “самого умного”. Растите дублирующих специалистов. Пишите документацию. Один супермен — это риск, а не преимущество.
Коромысло с одним ведром — всегда перевесит в одну сторону.
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
О возвращеніи къ истокамъ: почему дореволюціонная орѳографія можетъ стать новымъ трендомъ въ IT
Или какъ перестать писать "плиз" и начать писать "извольте"
Привѣтствую, уважаемые обитатели Хабра!
Сидѣлъ я намедни за терминаломъ, читалъ коммиты, и вдругъ осѣнило меня: отчего это мы всѣ пишемъ "фиксы", "фичи" да "релизы", когда у насъ есть прекрасный русскій языкъ съ богатѣйшей исторіей? И рѣшилъ я возродить старую добрую традицію — писать по-русски, да не просто по-русски, а какъ писали наши прадѣды до революціи 1917 года.
Что же это за звѣрь такой — дореволюціонная орѳографія?
Для начала развѣю главный миѳъ: это не "языкъ Пушкина" и не "древнерусскій". Это вполнѣ себѣ обычный русскій языкъ, только съ болѣе сложными правилами правописанія, которыя отмѣнили большевики въ 1918 году "для упрощенія".
Основныя правила, которыя должен знать каждый уважающій себя разработчикъ:
Исправилъ досадный багъ въ обработкѣ данныхъ
- Передѣлалъ функцію парсинга
- Добавилъ провѣрку на нулевыя значенія
- Обновилъ тесты подъ новую логику
Или документацію:
## О методѣ getUserById()
Сей методъ служитъ для полученія пользователя по его идентификатору.
Возвращаетъ объектъ типа User или null, если пользователь не найденъ.
Какъ начать писать въ старомъ стилѣ?
Установите правильныя шрифты — нужны шрифты съ поддержкой ѣ, і, ѳ, ѵ
Настройте раскладку — есть готовыя рѣшенія для всѣхъ ОС
Изучите основныя правила — начните съ ъ и постепенно добавляйте остальное
Дисциплина ума — сложныя правила тренируютъ вниманіе къ деталямъ
Эстетика — старыя тексты выглядятъ солиднѣе
Заключеніе
Дореволюціонная орѳографія — это не просто "модный трендъ", это возможность вернуть красоту и глубину русскому языку въ IT. Вмѣсто безликихъ "окей" и "сабмитовъ" мы можемъ писать "извольте" и "представляю на разсмотрѣніе".
Начните съ малаго — поставьте ъ въ концѣ своего ника. Напишите одинъ коммитъ въ старомъ стилѣ. Создайте README съ ятями. И увидите — за вами потянутся другіе.
Ибо, какъ говорили наши предки: "Безъ корней дерево не стоитъ".
P.S. Если статья понравилась, могу написать туторіалъ по настройкѣ vim для работы съ дореволюціонной орѳографіей.
Целевая аудиторія: Системные администраторы (бородатые хранители серверовъ и блюстители традицій)
Хабы:
Системное администрированіе (ибо кто какъ не админы цѣнятъ традиціи)
IT-стандарты (старая орѳографія — тоже стандартъ, только забытый)
Ненормальное программированіе (писать съ ятями — это вамъ не Hello World)
История IT (а что, развѣ языкъ — не часть исторіи?)
Читальный залъ (для любителей изящной словесности)
ITSM (IT Service Management, управление ИТ-услугами) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования оптимального сочетания людей, процессов и информационных технологий.
CI/CD (CICD) — методология разработки программного обеспечения, представляющая собой комбинацию непрерывной интеграции (continuous integration) и непрерывного развертывания (continuous delivery, или continuous deployment)
Если рассматривать "IT" как набор услуг (под управлением ITSM), не вступает ли это в противоречие с "CI/CD" (а может и с devops в целом)?
Здесь, я не имею в виду ситуацию "если родина прикажет" или "бизнес так решил", а в принципе.
Допустим, клиент заказывает услугу. Услуга имеет описание, а также, возможно, набор регламентов по использованию. Таким образом, клиент точно знает, за что платит, предполагая, что услуга имеет законченный вид и изменениям не подлежит, иначе, на каждом шаге, потребуется перерасчет, а это дополнительные временные и, возможно, финансовые издержки.
С точки зрения клиентоориентированности, в первом приближении, ITSM выглядит привлекательнее.
Но, у поставщика услуг, внезапно, CI/CD и другие "гибкие методологии разработки" (ну, допустим), а это означает постоянные изменения, как в наборе функционала (в составе предоставляемой услуги), так и в инфраструктуре проектов. Кроме того, по причине применяемых принципов, возможны разнообразные сдвиги сроков, что тоже не добавляет клиенту уверенности в завтрашнем дне.
Как потребителю услуг (клиенту), в этой ситуации, когда "всё течёт - всё меняется", быть уверенным, что он оплачивает и получает именно то, что требуется, да ещё и в полном объёме?
Выглядит так, что всё должно сойтись где-то на стыке одного и другого, но остается вопрос: а можно ли всё это красиво подружить?
По этой теме, я уже прочёл одну-две статьи, где-то на просторах интернета, но ссылки на них оставлять здесь как-то стыдно: они не отвечают на поставленные вопросы, просто постулируя - "да, можно"/"нет, не противоречит" или повествуют о том, как с одного перейти на другое, что, мягко говоря, обескураживает.
Кейс. Как Альфа-Лизинг интегрировал в ESM-платформу 9 отделов (ИТ, HR, АХО, бухгалтерию и др.) и повысил эффективность их работы на 33%
Знакома ситуация, когда процессы разных подразделений — разрозненные, неподконтрольные, а сотрудники тратят часы, чтобы просто понять: «к кому обратиться?». HR живёт по одним правилам, ИТ в Service Desk или ITSM — по другим, АХО — вообще в Excel. Вопросы теряются в переписках, задачи дублируются, никто не несёт полной ответственности за сроки или качество внутренней услуги. В итоге страдает не только конечный потребитель услуги — ваш сотрудник или клиент, но и бизнес из-за низкой производительности отделов.
10 июня на примере Альфа-Лизинг вы узнаете, как компания совершила эволюционный переход от классического ITSM к полноценной ESM-модели, объединив более 9 бизнес-подразделений (ИТ, HR, АХО, бухгалтерию и другие) в единой цифровой среде и повысила операционную эффективность подразделений на 33%, окупив внедрение ESM-платформы за 7 месяцев.
🚚💻 Как международный логистический лидер оптимизировал 790 000 транспортных операций в год: секреты управления ИТ-процессами в логистике
А именно: ➖Как добился 99% точности соблюдения сроков доставки? ➖Оптимизировал работу 22 региональных кросс-доков? ➖Успешно перешел с западной ITSM на российское решение?
Вы узнаете: ✔️Как цифровизация влияет на эффективность 3PL-оператора ✔️О рабочих практиках управления ИТ-процессами в конкретном бизнесе ✔️Как ITSM-система помогает управлять >700 ТС в транзите ежедневно ✔️Почему отказались от ServiceNow и что получила взамен
🎙 Спикеры: ➖Андрей Никитин, руководитель группы информационных систем, FM Logistic; ➖Иван Казачков, старший руководитель проектной группы ICL Soft; ➖Татьяна Праприна, менеджер по сопровождению ключевых клиентов SimpleOne.
Узнайте, как оптимизировать свою логистику на примере лидера рынка!
В YADRO есть команда, которая разрабатывает и отлаживает UEFI для самых разных продуктов компании. Подробнее о ней — в видеоролике → .
Первая особенность работы — в распределенной команде. Серверы, на которых инженеры разрабатывают прошивки, могут находиться в Москве, а разработчики — в других городах: от Владивостока до Калининграда и от Архангельска до Смоленска.
Системы, для которых разрабатывают прошивки в YADRO, делятся на два типа: с BMC и без него.
Больше о работе команды и, в целом, об истории BIOS/UEFI читайте в статье →
А если тоже хотите стать «поваром» UEFI, присмотритесь к одной из вакансий:
🗓 19.03.1964 - Старт жизни семейства ЭВМ System/360 [вехи_истории]
🗓 19.03.1964 - Старт жизни семейства ЭВМ System/360
Руководство IBM приняло ключевое решение о разработке семейства мейнфреймов System/360, анонсированного чуть позже - 7 апреля 1964 года. Это была первая линейка компьютеров с четким разделением архитектуры и реализации, обеспечивающая совместимость программного обеспечения между разными моделями.
В отличие от предыдущих систем, все модели System/360 – от маломощных до высокопроизводительных – использовали единый набор команд, что позволяло компаниям легко модернизировать оборудование без переписывания программ.
System/360 заложила основу для последующих серий IBM – 370, 390 и System z, а ее архитектура стала стандартом для индустрии. Благодаря этой системе в вычислительной технике утвердились 8-битные байты, 32-разрядная архитектура и шестнадцатеричная система исчисления. В СССР аналогом IBM/360 стали компьютеры ЕС ЭВМ.
🎞 Если ролик про IBM только находиться в производстве, то ролик про микроэлектронику СССР вы уже можете посмотреть на канале) Как 2 АМЕРИКАНСКИХ Шпиона ОСНОВАЛИ микроэлектронику в СССР YouTube | RuTube
Друзья, приглашаем вас в GlowByte на презентацию книги Брюса Сильвера «BPMN метод и стиль». Книга была переведена и издана Ассоциацией BPM-профессионалов благодаря спонсорской поддержке GlowByte и ELMA.
Брюс Сильвер – признанный авторитет в мире BPMN, непосредственно участвовавший в создании стандарта BPMN 2.0., и выход его книги на русском должен способствовать культивации «хорошего» BPMN.
После презентации состоится автограф-вечеринка, на которой вы сможете пообщаться с коллегами, зарядиться позитивными эмоциями и приобрести книги «BPMN метод и стиль» и BPM CBOK 4.0 с автографом научного редактора перевода, президента Ассоциации BPM-профессионалов Анатолия Белайчука.
В качестве бонуса члены Ассоциации могут получить членский значок.
Когда: 25 февраля 2025 г.
19:00-21:00
Где: Education Bar GlowByte (Москва, Нижний Сусальный переулок, 5 стр. 19, -1 этаж)
IT касается каждого — даже тех, кто в этой сфере не работает 🙌
Каждый день мы созваниваемся с коллегами. Заказываем еду. Обмениваемся фотографиями в соцсетях. Условия базового комфорта для нас реальны в том числе благодаря технологическим решениям на инфраструктуре Selectel. Присутствие этих связей невозможно заметить, но их отсутствие ощутится сразу же. Сняли ролик, в котором показываем невидимые линии, соединяющие нас с IT-инфраструктурой.
Работа с любовью клиентов — настоящее искусство. Рассказываем, что мы делаем, чтобы повысить лояльность аудитории 👀
В Selectel есть Customer Care — отдел, который отвечает на обращения пользователей. В одном диалоге с нашим специалистом клиент может решить разные вопросы. Например, оставить предложение по поводу доработок или уточнить нюансы настройки продукта.
Главная задача директора по сопровождению ключевых клиентов Татьяны Свирко и ее команды — сделать так, чтобы компании хотели поддерживать партнерские отношения с Selectel как можно дольше.
Но как измерить настолько тонкую материю? Чем вообще Customer Care отличается от техподдержки? Как убедиться, что отдел работает эффективно? Ответили в новом выпуске подкаста «А может, голосом?».
Смотрите видео и ставьте лайк, если вы, как и Таня, считаете стикеры с котами универсальным способом выражения эмоций 😎
Найти слабое звено: делаем команду эффективнее без перегруза
Слабое звено — это участок работы, из-за которого рушится весь процесс. Выявить его помогает теория ограничений, она же ТОС (Theory of constraints). Ее разработал, а затем подробно описал физик Элияху Голдратт в 1984 году.
Фундамент теории — пять шагов непрерывных улучшений, которые повышают эффективность в разы и помогают увидеть рабочий процесс целиком, а не фрагментарно. Вот эти шаги:
Найти узкие места. Это самые слабые звенья во всей производственной цепочке, те моменты, которые тормозят завершение проектов.
Решить, как использовать их с максимальной эффективностью. Нужно добиться максимальной отдачи от найденного ограничения, т. е. усилить слабое звено. Удалить все препятствия.
Подчинить всё этому решению. Важно направить все имеющиеся ресурсы на решение конкретной проблемы/ограничения. Вся система должна работать на расширение узкого места.
Расширить ограничение системы. Нужно найти способы сделать пропускную способность узкого места выше, чтобы оно перерабатывало больше задач, чем раньше.
Повторять цикл. Если ограничение устранено, необходимо вернуться к первому шагу — снова найти самое слабое звено и работать с ним.
Как заменить скомпрометированные отпечатки пальцев? Если кто-то завладел вашим отпечатком и распечатал его на чем-то? Как декомпрометировать? А никак. Завладевший вашим отпечатком будет ходить вместо вас в банкомат за деньгами.
Процесс создания возможности использования украденных отпечатков уже давно начат. Еще в 2020. Вот статья на Хабре: https://habr.com/ru/news/501958/
С одной стороны Касперские предлагают заменить свои отпечатки на кольцо с отпечатком. А с другой стороны создают способ для удобного использования украденных.
Проблема с отпечатками пальцев проста. Рано или поздно все базы данных взламываются. Чаще всего изнутри по паролю персонала. И попадают к злоумышленникам. И ваши пароли (и мои ) рано или поздно украдут. И отпечатки тоже. Но пароли заменить можно, а отпечатки нельзя. Об этом беспокоятся Касперские когда хотят сделать кольцо - заменитель отпечатков. И вместо того, чтобы вы прикладывали свой бесплатный палец надо будет прикладывать купленное у них кольцо. Что конечно ничуть не лучше прикладывания телефона.
Какой может быть выход со всей этой биометрией? Можно например использовать отпечатки от половины пальца. Или отпечатывать пальцы по очереди. Если скомпрометировали ваш указательный палец, то переходим к безымянному. К пенсии уже дойдем до мизинца на ноге, что бы дверь в офис открыть.
Может быть надо отменить всю эту тему с отпечатками пока не стало поздно? Вернуться к паролям и токенам и вернуть людям право на смену украденного пароля на новый?
