Мы недавно рассмотрели интересную тему про «бизнес в заложниках у IT». Теперь для симметрии нужно рассмотреть обратную сторону: «IT в заложниках у бизнеса». Честно говоря, в эту игру всегда играют двое, а бизнес далеко не такой беззащитный, как это кому-то может показаться. Хороший бизнесмен обладает не менее развитым системным мышлением, нежели квалифицированный IT специалист. Кроме того, у бизнеса свои рычаги влияния, которыми он умеет хорошо пользоваться. Статья будет полезна обеим сторонам, чтобы лучше понять друг друга.
Продолжаем тему, почему внезапно в IT «всё перестало работать». Мы уже рассмотрели, что может сделать бизнес-заказчик, когда IT хронически срывают сроки. Затем мы поняли, что такое технический долг и почему без его выплаты не получится восстановить работоспособность IT. Но есть и другая серьёзная проблема, с которой рискует столкнуться бизнес, работая с IT. Это работа IT в подходе JSDD (Job Safety Driven Development). На эту тему уже была несерьёзная статья, теперь будет серьёзная. Заодно рассмотрим возможные выходы их ситуации.
Срыв сроков и выход за оценки в IT — большая и многогранная тема. На что-то бизнес-заказчик может повлиять напрямую, на что-то лишь косвенно. При работе с IT очень желательно понимать и знать такие понятия, как технический долг и «технический дефолт» (имеет иное значение, нежели в экономике). Что это такое, какие последствия имеет и как с эти бороться сейчас разберём.
Срыв сроков и выход за оценки - довольно частая и болезненная проблема бизнеса при взаимодействии с IT-специалистами. Иногда срывы сроков и выходы за оценки начинают приобретать хронический характер и встаёт острый вопрос: «Что же с этим делать?». Давайте рассмотрим, какие действия могут предпринять «неайтишники», чтобы выйти из ситуации. Сразу скажу, что слова: «Просто напишите нормальное ТЗ» - не прозвучат.
Это сложная тема, которая периодически всплывает в среде IT-специалистов, об этом сказано уже немало, а вот для «неайтишников» многое может оказаться новостью. Как для тех, кто хочет «войти в IT», так и для тех, кто по роду своей деятельности вынужден работать вместе с IT-службами. Некоторые вещи будут очевидны для IT-специалистов, но не очевидными для других. Иногда из-за их непонимания люди допускают болезненные ошибки. Не только и не столько со своей карьерой, сколько в своём бизнесе делают ставку не на тех людей. Поэтому, давайте разберём этот вопрос без эмоций и на понятном для неспециалистов языке.
Мы давно живём в цифровом мире, нас окружают полезные онлайн-сервисы, видеохостинги, стиминговые площадки, платформы для блогеров, новостные агрегаторы, интернет-магазины, маркетплейсы и многое другое. В этом мире живут не только IT-специалисты, в нем живём мы все вместе. Но до сих пор при общении между IT-специалистами и «неатишниками» возникает много непонимания, которое выливается во взаимные претензии. IT-специалисты часто жалуются о том, что их заставляют заниматься бесполезным трудом и не могут нормально сказать, чего от них хотят. Со стороны «неайтишников» часто слышится: «Ох уж эти программисты, опять долго, дорого и не то». Давайте разберёмся зачем IT и цифровизация нужна для неайтишников и как ими правильно пользоваться. На простом и понятном обеим сторонам языке.
В области информационных технологий традиционно уделяется большое внимание и процессам, и людям. Неудивительно, ведь с одной стороны работает большое количество людей, их совместную работу нужно организовать с помощью какого-то процесса. С другой стороны, эффективность работы людей в ИТ непропорционально зависит от их личных особенностей. Часто замена технических инструментов на более совершенные даёт заметно более низкий рост производительности, чем профессиональное развитие сотрудников. При этом обычно забывают о главном, что процессы выполняют люди, которые могут их выполнять самым неожиданным образом, вплоть до получения обратного запланированному результату. Ещё забывают, что процессы сильно меняют поведение людей, которые их выполняют. Многие проблемы в ИТ происходят именно из-за неверного понимания совместного действия людей и процессов. Тема необъятная, писать можно много. Эта статья о самом базовом, как образуется и растёт команда, которая будет потом выполнять какие-то процессы каким-то образом. Попробуем разобраться в сути вещей. Написать просто и понятно уже не обещаю.
В статье «Почему всё ломается даже у хороших программистов?» (Часть 1 и Часть 2) был описан тип сотрудников: «золотая шестерёнка». Это способные люди, которые являются не только замечательными разработчиками, но ещё являются хорошими организаторами, имеют стратегическое мышление, могут проектировать архитектуру приложения либо даже ИТ-ландшафт. Встаёт закономерный вопрос, а почему «золотые шестерёнки» это плохо, почему бы из них не собрать сильную команду, чтобы всем было счастье. Давайте попробуем понять, почему «золотая шестерёнка» в итоге зачастую дестабилизирует ситуацию вокруг себя. Писать буду простым языком в расчёте на широкую аудиторию.
После несерьёзной статьи на серьёзную тему Job Safety Driven Development возникла идея написать о том, как появляются ошибки разработчиков. Вместо этого появилась статья «Почему всё ломается даже у хороших программистов?» (Часть 1 и Часть 2). Мысль нужно закончить. Уже рассмотрено два краевых случая, давайте посмотрим и на «обычные» причины ошибок программистов. В первой части этой статьи мы рассмотрели, что такое ошибка вообще, цену и ценность ошибок, немного коснулись темы интерактивного программирования и разработки через багфикс. На примере "ошибки выжившего" поняли, как формируются негативные паттерны поведения. Здесь же мы рассмотрим проблему оптимизации, которая по своей разрушительной силе не очень уступает разработке через багфикс. Посмотрим, а нужны ли программисту фундаментальные знания, а если да, то зачем. И попытаемся затронуть проблему слепого копирования ритуалов (карго-культ) в программировании. Продолжаю пробовать писать простым языком, чтобы было понятно широкой аудитории.
После несерьёзной статьи на серьёзную тему Job Safety Driven Development возникла идея написать о том, как появляются ошибки разработчиков. Вместо этого появилась статья «Почему всё ломается даже у хороших программистов?» (Часть 1 и Часть 2). Мысль нужно закончить. Уже рассмотрено два краевых случая, давайте посмотрим и на «обычные» причины ошибок программистов. Тема необъятная, поэтому затронем только основные моменты. Эту статью тоже пришлось разбить на 2 части (Часть 2). Как всегда, попробую писать простым языком, понятным широкой аудитории.
После несерьёзной статьи на серьёзную тему Job Safety Driven Development стоит рассказать о том, почему даже опытные и добросовестные программисты волей случая могут попадать в схожие ситуации. Сначала захотелось написать, почему программисты ошибаются вообще ("Почему ошибаются программисты?" Часть 1 и Часть 2), но оказалось, что это слишком разные темы. Потом оказалось, что и на эту тему получился очень длинный текст. Пришлось разбить его на части. В первой части мы рассмотрим обычные случаи, которые знакомы многим крупным компаниям. И дополним понятие «серебряная пуля» понятием «золотая шестерёнка». Во второй части поймём, какую цену вам, скорее всего, придётся заплатить за «золотую шестерёнку», я приведу немного своего опыта. Как всегда, попробую писать простым языком, понятным широкой аудитории.
После несерьёзной статьи на серьёзную тему Job Safety Driven Development стоит рассказать о том, почему даже опытные и добросовестные программисты волей случая могут попадать в схожие ситуации. Сначала захотелось написать, почему программисты ошибаются вообще ("Почему ошибаются программисты?" Часть 1 и Часть 2), но оказалось, что это слишком разные темы. Потом оказалось, что и на эту тему получился очень длинный текст. Пришлось разбить его на части. В первой части мы рассмотрим случаи, которые знакомы многим крупным компаниям. И дополним понятие «серебряная пуля» понятием «золотая шестерёнка». Во второй части поймём, какую цену вам, скорее всего, придётся заплатить за «золотую шестерёнку», я приведу немного своего опыта. Как всегда, попробую писать простым языком, понятным широкой аудитории.
Это несерьёзная статья на серьёзную тему. Есть такое понятие, как JSDD - Job Safety (Security) Driven Development, мы часто видим его в крупных компаниях. От этого не избавлены и небольшие компании, особенно когда в штате всего несколько программистов. Разработчики пишут свой код столь изысканным способом, что, несмотря на очень низкую скорость разработки, их страшно уволить, потому что, кроме них, этот код никто понять не сможет. Давайте попробуем разобрать, почему и как такое происходит.
Есть много разных методологий разработки: Waterfall, Agile, Lean и другие. Ситуацию усложняют различные схемы оплаты разработки в ИТ. Что лучше: Fixed Price, Time&Material или взять людей на аутстафф? Человеку, далёкому от коммерческой разработки, бывает сложно разобраться что и когда стоит использовать. Чтобы помочь с этим разобраться, рассмотрим разные методологии и схемы оплаты с точки зрения работы с рисками и права на ошибку. Попробую писать простым языком, чтобы было понятно всем.
