👉️ Прошлый пост про Женю

Небольшое продолжение. С кириллицей chatgpt все еще плохо работает. Чуть пришлось доработать, т.к. персонаж на второй панели был уже лысый =D . Перетаскивал лицо с первой картинки и накладывал поверх. Попрактикуюсь, может и найду идеальный подход в создании комиксов, а пока просто делюсь очередной историей разраба Максимуса

Рассуждения Forbes о необходимости юридической проверки ПО при сделках с IT компаниями и две реальные истории из жизни о наё.. при продажах ПО для B2B

Код в мешке: за что платят покупатели ПО?

Попалась на глаза заметка в Форбс о том, что сектор технологий, медиа и телекоммуникаций сохраняет лидерство по количеству сделок M&A, и что в этом сегменте высок процент сделок в сфере soft-driven.

В переводе на человеческий: сейчас происходит много объединения активов компаний, а по-простому – слияний и поглощений. И очень часто в технологическом сегменте предметом сделки является ПО.

И, пишет Форбс, есть в этой истории изрядная заноза: покупатели активов частенько приобретают код в мешке. Ведь ПО – объект интеллектуальной собственности, он охраняется авторским правом, и далеко не всегда сам разработчик в курсе, что у него проблемы с правами на программный продукт. Или купила ваша компания уникальное ПО за все деньги мира – а потом оказывается, что не такое уж оно уникальное и сотни его копий напродавали другим компаниям.

Поделюсь парой историй на эту тему. Все названия изменены, вся фактура истинна.

«Вот такой же, только меньше, но другой» История первая.

Однажды мы собеседовали крутого айтишника и спросили, что случилось с предыдущим местом его работы. И человек рассказал дивное.

Последняя его работа была проектная, в маленьком и гордом IT-стартапе, который создал действительно уникальную платформу для криптовалютных торгов. У стартапа было несколько собственников, которые рьяно и с огоньком вели переговоры о продаже ПО с разными покупателями. И как-то так случайно (наверное) получилось, что ПО продали дважды, двум разным юрлицам.

Когда это обнаружилось, настала паника, хаос и каннибализм. А потом нашего героя пригласили на проект, чтобы организовать команду кодеров и быстренько на основе исходного ПО создать вот такую же, но другую систему. И загнать её второму покупателю как совершенно уникальную и ту самую, за которую он исходно заплатил.

И систему создали. И продали. И никто ничего не заподозрил. Все остались счастливы, кроме здравого смысла, совести и пары-тройки законодательных актов.

Приключения в концерне «Семицветик». История вторая.

Однажды компания «Лепесток», входящая в большой концерн «Семицветик», подписалась разработать для управляющих компаний своего города некое ПО. Конечно, это лишь совпадение, что задачу передали на аутсорс разработчику из Таганрога, с которым у руководства «Лепестка» были прочнейшие деловые и дружеские связи. Настолько дружеские, что некоторые сватья-братья работали в этих компаниях перекрёстно.

Таганрогский разработчик создал ПО и передал «Лепестку». Поскольку свои люди какашек не подсунут, руководство «Лепестка» оплатило продукт не глядя. А вот сами заказчики ПО оказались людьми вредными, бессердечными и проверили, что им принесли. И работу не приняли: ну кто бы мог подумать, что реальный функционал ПО совсем не натягивался на глобус поставленных задач!

Тем временем таганрогской разработчик внезапно и тихо перестал существовать, а его руководитель столь же тихо десантировался со всем накопленным баблом в далёкую тёплую страну. А ведь только что же всё в порядке было!

Руководство «Лепестка» честно пыталось спасти ситуацию, вбухивая самосвалы бабла в доработку софта, но без толку: проблема была в самой архитектуре ПО. Если вам требуется ледокол, то его и нужно строить. А если под видом ледокола вам продали речной трамвайчик, то как его ни апгрейди – всё без толку.

Я в то время работала в «Лепестке» по совсем другому проекту и оказались в курсе этой истории лишь потому, что вся компания с утра до ночи бегала и орала. Не зря: когда вся история дошла до руководства концерна, головы и должности полетели во все стороны.

А что надо-то было? Да провести экспертизу ПО перед приёмкой и не платить за код в мешке!

С другой стороны, вот написали мы это и задумались: ну ок, провели вы экспертизу, а кто сказал, что её заключение корректно? Ведь аудиторы всё ещё не несут ответственности за свои ошибки…

Так, друзья и подписчики, если вам приходилось проверять поставленный код на соответствие задаче – поделитесь опытом: куда бежали, кому кричали, что получили в результате?

Научная организация труда

За идею из комментария спасибо @OldGarry

🙀 Телеграм-канал

Ссылка на канал с мемами: m e m e l o s a u r u s

Есть один древний айтишный закон: чем меньше ты понимаешь, что делает человек — тем выше у него зарплата. Встречайте: менеджеры. Эти загадочные создания умеют не писать код, не настраивать пайплайны, не читать логи, но при этом всегда как-то рядом, когда дедлайн уже дышит в лицо. Они генерируют задачи, меняют приоритеты с частотой пульсара и при этом смотрят на тебя, как будто это ты сломал прод, хотя сам прод только что услышал о своём существовании.

Так что, если ты когда-нибудь задавался вопросом, почему ты ночью фиксил баг, а премию получил Начальник— расслабься. Ты не один. Добро пожаловать в реальность IT-проектов, где менеджер может «перепутать цели» и остаться героем, а ты — будешь чинить последствия этой «перепутки» следующие 3 спринта.

Представьте себе классический проект с душком: сроки вчера, бюджет — шутка, документации нет, наставника нет, но есть жгучее желание выжить.

Теперь теперь хочу поделиться этим всем с привкусом боли и горелого продакшна:

---

Как я выживал на проекте, где даже ТЗ не успело родиться

Когда ты заходишь в новый проект и тебе говорят: "Ну, тут всё просто, надо чуть-чуть пособирать требования", — знай: тебя только что вписали в экшн-квест на выживание без оружия и карты. Так было и у меня. Делюсь опытом, чтобы вы не повторяли моих ошибок (или хотя бы делали это красиво).

Что успел наклепать за время танцев с бубном:

- Провёл предпроектную подготовку — то есть выжег себе глаза, разбираясь, что тут вообще происходит.

- Набрал команду с нуля — по сути, нашёл таких же бедолаг, которые согласились в это вписаться.

- Погонял тендеры — это когда ты не выбираешь лучшее, а выбираешь меньшее зло по цене.

- Запилил процессы бизнес-анализа и интерфейсного EX — EX, потому что UX там, в том проекте, благополучно умер задолго до моего прихода.

- Написал архитектурные документы, которые, скорее всего, никто не читал, но которые всё равно нужны, чтобы не думать об их отсутствии по ночам.

- Провёл командную сессию — это когда ты зовёшь людей на Zoom, а они в ответ шлют «+» в чат и молчат.

Атмосфера на проекте? Уют, как в дата-центре при +45 без кондиционера.

Ты на проекте один. Нет наставника. Нет онбординга. Границы ответственности не то что размыты — их вообще нет. Все полезные материалы и контакты надо вылавливать у случайных встречных, как в RPG с кривым AI. Каждый день как экспедиция в зону отчуждения.

---

Теперь про проект "А" — или как не надо делать проекты

Тут всё было по классике жанра «дичь»:

- Никакой предпроектной подготовки. Просто «вот тебе идея — делай».

- Контактной группы не было. Видимо, предполагалось, что я общаюсь с воздухом или призраками прошлых сотрудников.

- Бизнес-требования были… как бы помягче… не по адресу. Их пришлось выкинуть и писать с нуля.

- Про данные никто не договорился. Какие данные? Откуда? Зачем? Да кто его знает.

- Требования были такие, что если бы мы их реализовали, проект стоил бы как Илону Маску полёт на Марс.

- Ну и логично — меня оттуда выпилили и отправили в проект "Б". Классическая эвакуация с тонущего корабля на другой, который пока только загружается.

---

Проект "Б". 2.0" — ремейк с нотками ада

За один календарный месяц я успел:

- Протащить бюджетирование (да, цифры взял с потолка, как и все нормальные люди, но красиво).

- Сделать карту рисков — спойлер: весь проект один сплошной риск.

- Составить контактную карту — теперь хотя бы знаю, кому звонить, когда всё опять рухнет.

- Зафиксировать расширенные бизнес-требования — такие, что если бы всё реализовали, нам дали бы премию и уволили, потому что слишком умные.

- Обновить устав ПО, расписать Гант, заревизить и вообще разгрести завалы прошлого века.

- И да, встреч провёл на 10+ часов. В основном — слушал, как люди пересказывают слухи и гадают, чего же хочет бизнес.

---

Немного о токсичности (не среды, а менеджмента)

Есть у нас такой персонаж — Евгений. Управляет проектом по принципу: "Что вижу — то поношу". Эмоциональные решения, поверхностный анализ, Zero вовлечения. Честно? Работать в таких условиях — всё равно что собирать прод под артобстрелом. Я предлагаю хотя бы на время этот "артобстрел" отключить. Просто ради вменяемости оставшихся сотрудников.

---

Вывод

Если вы только входите в мир системного анализа, DevOps или управления IT-проектами — готовьтесь страдать, но делайте это с умом и юмором. Всё равно в какой-то момент вы окажетесь в проекте, где нет ничего, кроме дедлайна, Excel-файла 2017 года и менеджера, который «передумал».

А если вы уже там — держитесь. Пейте кофе, пишите документацию и логируйте всё, включая свои нервные срывы.