kapa

Только это все вообще не о софте и даже близко к нему не относится. +1 30 лет в софте....столько не живут. Мы работаем по Agile около 6 лет. Документация есть. Все знают где что стоит/лежит и почему. Или знают где уточнить. На канбан-доске даже есть столбец специальный - документирование.

Слишком оптимистично. Это смотря с какой стороны посмотреть. Возможно слишком пессимистично. Выходит, что это просто жизненно :) Если есть исчерпывающая документация, но нет работающей системы, то есть некая вероятность, что кто-то другой сможет систему доделать и потом растиражировать/приспособить в разные места для нашей пользы. А если есть работающая система, но нет достаточной документации - то система останется в единственном числе. Ну или придется делать все с нуля/заниматься исследовательскими работами заново. И что важнее получается? Но без работающей системы, мы не можем быть уверенны, что документация у нас от чего-то работающего.

Там выше. Так вот. Это он сейчас работает. Пока разработчики еще есть и могут быстро починить, если сломалось. А когда они это делать перестанут? Ну так он же всё равно важнее :) Ведь, когда наступит "сломалось", возможно и чинить не нужно уже будет?

Agile же не против документации.

А почему свалить? Это разве не его зона ответственности? Ну нам отмазаться или бабла заработать? Ну, допустим, его. А работу потеряли все. А в этом 'посреди разработки' постановщик что, не участвует уже? И этого нового понимания никак не видит? Ну так я к тому, что железно следовать ТЗ не всегда полезно. Но не забываем, что этот стиль разработки сильно игнорирует, что будет с продуктом потом. Когда начальной команды уже нет, а что-нибудь изменить под новые условия надо. Или хотя бы просто продукт из эксплуатации вывести, заменив новым. Но не потеряв чего-нибудь важного. Чем железное следование ТЗ всё меняет?

мы разрабатываем что бы оно работало и приносило чтото полезное конторе или делаем ради делать?) Мы разрабатываем чтобы оно работало и приносило что-то полезное конторе, или делаем ради того, чтоб потом свалить ответственность на постановщика задачи? И пофиг, что он из соседнего отдела, и мы, поняв посреди разработки, как можно было бы сделать лучше, чделали всё по ТЗ и потеряли или недополучили кучу бабла? Манифест Agile:

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

Вообще не аджайл стайл. :) Я так понимаю, что разработка внутренняя. Множество вещей разрабатываются в первый и последний раз. В такой ситуации можно и НУЖНО менять ТЗ. Мало того - пытаться сразу разработать железобетонное ТЗ вредно.

И меня! И тоже не понравилось! :) На курсере сейчас больше полезного.

Зато оплату труда можешь. И суммарно закупки + фот. ФОТ чуть больше 20%, но там в закупках может быть огромное количество бабла сторонним бригадам. Но с другой стороны, и железа разного совсем, начиная с магистрального, заканчивая мелким железом на продажу абонентам. Чего сколько внутри и в каких пропорциях - только гадать можно.

http://mgts.ru/upload/images/r/Godovaya_bukhgalterskaya_finansovaya_otchetnost'_za_2015g.pdf а поговорить? :) Я там не могу аутсорс от закупки товаров отделить. В итоге сравнить не выходит.

забыл написать же! (да, я асёл) Чего прям сразу асёл-то? :) Хорошая статья. Мне просто интересно - по отрасли в основном у остальных такие же цифры или это ЭРы до сих пор где-то активно строятся?

короч, я тут факапнул. У меня ж была задумка еще один раздел дописать про производительность. Но что-то помешало :) сейчас лень. Но в источнике есть все цифры в смысле? цифры перепутал?

Вот поэтому я всё время клоню к тому, что нужно искать тех, кто хочет учиться, а не отправлять кого-то на учёбу. В идеале ещё, чтоб человек за свои готов был учиться. Или впополам предлагать. Тогда будет хоть как-то мотивацию видно.

Я ходил на что-то там от Майкрософта (лет ооочень много назад) и на первый ITIL. Оба не понравились. Но ITIL заинтересовал, и я потом очень много в нём ковырялся сам. Сертификацию, разумеется, не получал. Но если надумаешь кого-то на основы ITIL посылать, то я бы с него сертификацию требовал - прослушать курс мало.

Ладно, для целей возникновения холивора, попробую сделать короткие выводы, так сказать, не официально :) Но сумбурно, извините. В общем, суть телеком-бизнеса - вложить бабло с целью построить сеть. А потом, типа, сидеть, и собирать бабло. Но на самом деле, этот процесс чуточку сложнее. Вот в эту яму "сначала много денег, а потом стричь купоны" и попал ЭР. Кстати, за ним следует еще и, например, Теле2. С целью поддержания разговора поинтересуюсь. Вот в виду того, что ты понаписал про сначала вложить, а потом собирать. Не дохрена ли жрёт у ЭРов ФОТ с аутсорсом и соц. выплатами? в 2015 - 65,5% от расходов или 55% от выручки в 2016 - 58,5% от расходов или 52% от выручки Где экономия на масшабе? :)

Есть ещё путь. Назови анархию холакратией, раздай опционы, все кааак замотивируются бабки считать и не предлагать лишнее, а потом и о порядке разработки договорятся. Заодно дополнительные бабки сможешь зарабатывать рассказывая за бабки другим на конференциях, как ты новый баззворд внедрил, и водя к себе экскурсии ;)

Вот не вижу я тут потенциала для кратного роста. Простой список в экселе для упорядочивания по статусу при повторных проходках по списку - вот что даст максимальное ускорение. Если деньги, вложенные в разработку, передать на премирование по результатам (т.е. не по количеству перебранных по базе телефонов, а по количеству привлечённых абонентов), то вот это максимально увеличит производительность. Причём именно ту, которую голой автоматизацией тебе поднять не удастся. Потом кончатся абоненты :) Или тебе есть ещё что на регулярной основе физикам предлагать, да так, чтоб они тебя в чёрный список не занесли? Делись ;)

Я сейчас отвечу вопросом не на тот вопрос, что ты задавал :) Тимур, тебе не кажется, что конкретно этот вопрос при твоих масштабах больше управленческий? Посадить обзвонщиков на сделку от продаж и дать им списки в руки. По результатом первых обзвонов отсечь плохих обзвонщиков, перераспределить нагрузку в пользу хороших, поощрить причастных.... Хотя, можно, конечно, и автоматизировать немного. Там же на копейки разработки? И тот бюджет, который мог бы радовать в это тяжёлое время разработчиков порадует кого-то ещё :) Но мне кажется, что это просто неудачный пример у тебя. И смысл именно в том, что таких автоматизационных задач несколько десятков, и вот кто-то должен по ним собрать стоимости/сроки/эффекты и что-то запустить, а что-то притормозить? Ну так и найди такого человека из тех, кто рвётся? Мне кажется, что такой подход: не очень хорош тем, что эти несколько человек поедут в надежде оказаться тем самым человеком, все уже представят себя в его кресле, а в итоге большинство будет опущено на землю.

Прекрасно резюмировано! Конкретно с уклоном на софт - Принципы работы с требованиями к программному обеспечению. Унифицированный подход. На ближайшие полгода хватит, если внимательно читать а себе тестовые упражнения описанным методикам устраивать. Только надо бы кого-нибудь в компанию, чтобы результаты ругал. А то самому это делать - малопродуктивно. Есть у меня ощущение, что это не совсем то, что нужно. Но если вдруг, то для тех, кто не любит читать: https://stepic.org/course/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-%D0%BF%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B8-%D0%BD%D0%B0-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D1%83-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC-145/syllabus

Главная польза курсов - вырваться из операционной деятельности. Пока разбираешься с тем же ITIL, например, каждые несколько минут ловишь себя на мысли, что там сплошь очевидные вещи разбираются. Только вот пока ты весь в рутине погряз, тебе об этом подумать некогда, а тут уже подумали, систематизировали и выложили. Потом просто что-то из этого берёшь и применяешь. Или не применяешь, потому что понимаешь, что ещё рано.

Какой ITIL? Второй или третий, который стал 2011? Мне довелось работать во втором, но вот третий люди называют уже серьезно перегруженным. Для этих целей без разницы. Достаточно основ, а дальше можно либо понять где что искать, либо просто мозги повернутся в нужную сторону.

В таком случае соглашусь с Тимуром. Берите готовое. Потом напишете своё или обвяжете взятое костылями.

Про постоянные модификации существующего в ITIL есть The CSI Register. Это как раз про то, что выбирать из массы альтернатив при ограниченности ресурсов. А потом уже как раз любой Agile - Scrum, Kanban...

ITIL это не про разработку. Про разработку это SWEBOK(про софт), и PMBOK(более обще). Но воспользоваться ими просто так и самому - как то нетривиально. Я понимаю что про что - я поэтому и вставил, что основываюсь на комментах в ФБ. А ITIL он про здравый смысл :) Он не мешал никому. Только частенько все это в значительной мере кажется. Это частенько выглядит как микрооптимизация кода, когда сам алгоритм тормозной. Но только чтоб узнать, что есть, а что кажется, нужно во многое вляпаться.