То для чего система не предназначена по определению гораздо больше, чем то для чего она предназначена, и поэтому прописать в ТЗ ВСЕ для чего она не предназначена вообще не возможно.
Конечно исходя из опыта прошлых проектов вы можете включить в ТЗ самые часто встречающиеся дополнительные требования, но во первых для этого сначала нужно таки наступить на грабли и это все равно будет дырявый зонтик.
Поэтому assumptions лучше прописывать в позитивной форме. На основе знания о вашей системе.
Например для вашего случая:
«до начала использования механизма синхронизации данных небходимо провести первоначальную загрузку данных методом А»
А это прописать в Нефункциональные требования:
«подразумевается что объём ежедневной передаваемой информации для механизма синхронизации меньше 100000 записей»
С другой стороны, при наличии нормальных отношений с заказчиком, всегда можно объяснить что не нужно пытаться добиться от системы того для чего она не предназначена, даже если это формально не прописано в ТЗ. Все равно это не будет работать.
Так что ещё один важный вывод из ситцуации который нужно было сделать: Должны быть нормальные взаимоотношения с клиентом, без попыток втоптать друг друга в грязь и/или подставить на деньги.
Почему вы сравниваете свой продукт с Trello? Он вроде бы никогда не позиционировался как продукт для разработчиков. Сравнивайте с линейкой продуктов Atlassian которые предназначены для разработчиков (Jira, Confluence, bitbucket, Bamboo) это будет более корректно.
По моему все просто — «Team lead» прежде всего менеджер, наверное менеджер самого низкого звена но все же менеджер.
И как у всякого менеджера, его главная обязанность организация совместной деятельности группы людей необходимой для достижения некой цели.
Все остальное является побочными видами деятельности.
Он может быть одновременно разработчиком (или тестером, у тестеров тоже есть Team lead-ы) а может и не быть.
Он может совмещать роль архитектора или может доверить исполнение этой роли кому-то из своей команды.
Может быть самым квалифицированным специалистом своей команды, но это не обязательно.
Может быть самым умным, но если он будет опиратся при принятии решений в том числе на мнение более умных подчиненных, этого не требуется.
Чего он точно не может делать, это уклонятся от решения возникающих на пути к общей цели проблем.
Не может перекладывать отвественность за общие неудачи на другого.
Обязан добится приличной награды для подчиненного который снова сделал невозможное.
Ну а в целом про роль менеджера столько написано что нет смысла пересказывать.
Учите работы классиков и у Вас все получится )
«Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. „
Поднимитесь еще на одну ступеньку и почувствуете что эта должность еще более неблагодарная ))) Определенности в обязанностях еще меньше, а конкуренция за позицию неожиданно суровая и т.п.
Тут возможно просто требуется небольшая расшифровка для незнакомых с миром Энтерпрайз софтваре. Рискну предположить что:
Фронтальный = для взаимодействия с конечными потребителями, колцентры, веб-сайт, мобильные приложения и тп
Базис = значит что вместо того чтобы взять и интегрировать несколько готовых систем для веб сайта, колцентра и MA люди взялись за написание своего велосипеда… то есть платформы который умеет все это вместе в одном флаконе. Кому жалко денег так не делают…
Омниканальные процессы = это значит что при звонке в колнецтр Вас не должны спрашивать какую Карту вы оформили в офисе. А в мобильном приложении после регистрации Вас как пользователя, она должны отображается автоматически. То есть действие инициированное клиентом в одном из каналов Мобильное приложение, Офис, веб сайт или колцентр должно иметь продолжение в
Из контекста у меня сложилось ощущение что Dev так и не склеилось с Ops, или я ошибаюсь?
Так же интересно какие KPI используются для разработки? Надеюсь они напрямую влияют на зарплату каждого разработчика и это что-то отлично проверенное временем типа CLOC?
К сожалению не нашёл информации о том как устроена транзакционная модель (
Поддерживается ли ACID?
Что вообще происходит при конкурентной записи в таблицы? Поддерживается ли read consistency?
На самом деле GC не только зло но и добро. В управляемой куче память для новых объектов выделяется быстрее, почти так же быстро как на стеке так как выделение памяти в управляемой куче означает просто перестановку указателя. Другой момент то что с долгоживущими большими объектами у GC идеологическая проблема. Неуправляемая куча с другой стороны со временем фрагментируется и начинает тормозить выделение памяти. Но для того чтобы получить такой эффект требуется значительный uptime и на коротких тестах его разумеется заметно не будет.
Если вы воспринимаете Билла Гейтса и Стива Джобса как технических гениев из которых первый единолично написал Windows, а второй лично собрал на коленках первый iPhone, вы ошибаетесь. Все было с точностью до наоборот это были люди которые смогли вокруг себя собрать единомышленников, каждая из которых работая как одна команда смогли создать беспрецедентные прежде продукты. Предлагаю вам обратится к первоисточникам например на TED.com можно найти многочисленные интервью их обоих. Уверен Вам будет интересно.
С такими лучше сразу расставаться, они очень токсично влияют на остальную команду. А проекты все же делают не конкретные, пусть даже очень талантливые люди, а команды. Для достижения успеха вам нужна талантливая и мотивированная команда, а не ее отдельные «выдающиеся»… мемберы (хотел написать русское слово но подумал что выйдет двусмысленно).
Вообще люди часто раскрываются именно в составе команды и в процессе работы над проектом и ценными они являются именно как часть команды и в контексте проекта. Но то есть в звёзд которые сами по себе звезды я не очень верю. Хотя наш HR думает что именно такие люди нам нужны…
Если мне память не изменяет, эти ключевые слова были представлены MS как синтаксический сахар в компиляторе C++ в тулките для разработки под новое асинхронное API WinRT которое должно было заменить Win32. И это API было никак не связано с .NET. Это особо подчеркивалось, как мне помнится. .net и C# позже подтянулись. Так что первым языком в котором появились эти ключевые слова все же C++ ) правда не в ISO стандарте а в очередной интерпретации MS.
Нет, нет, не надо таких сравнений Линус Торвальдс тут не причём. Некоторые за такие сравнения и обидеться могут.
Darwin а позднее OS/X а ещё позднее снова macOS построен на ядре FreeBSD, настоящем Unix-е )
Хотя надо признать выбрали его как основу OS скорее из за лицензии, так как BSD лицензия позволяет не раскрывать код производных продуктов.
Я стесняюсь спросить но каким боком тут девопс? Если те самые идеи в головах бизнеса формулируются и превращаются в что то имеющее хотя бы форму юзер стори с непротиворечивыми акцептанс критериями иногда годами. Инженеры в своём большинстве понятия не имеют как это присходит и меряют тайм ту маркет от момента когда они видят юзер стори с макетами, а это процентов 10% от общего времени. И ускорение на жалкие проценты за счёт автоматизации развёртывания с точки зрения всего бизнеса являются исчезающие малыми. И никак не являются ключом к успеху компании.
Тут речь о том что поиск увлеченных людей для участия для работы в сервисной компании это фундаментальная ошибка. Потому что программная инженерия это вообще не разу не интересная штука. Это не написание блистательного кода в супер новом и крутом приложении, это джитуии приложения с тоннами чужого кода с устаревшими концепция в основе платформы. Это тупые митинги и бесконечные чаты, код ревью и написание документации в объёме большем чем объём кода, это бесконечное планирование и эстимации, это обучение новичков и попытки объяснить клиенту что так как он хочет сделать будет очень дорого. Вообще ничего интересного для тех кто увлечён программированием. Искать для такой работы звездных программистов это как минимум чудовищная глупость.
Конечно исходя из опыта прошлых проектов вы можете включить в ТЗ самые часто встречающиеся дополнительные требования, но во первых для этого сначала нужно таки наступить на грабли и это все равно будет дырявый зонтик.
Поэтому assumptions лучше прописывать в позитивной форме. На основе знания о вашей системе.
Например для вашего случая:
«до начала использования механизма синхронизации данных небходимо провести первоначальную загрузку данных методом А»
А это прописать в Нефункциональные требования:
«подразумевается что объём ежедневной передаваемой информации для механизма синхронизации меньше 100000 записей»
С другой стороны, при наличии нормальных отношений с заказчиком, всегда можно объяснить что не нужно пытаться добиться от системы того для чего она не предназначена, даже если это формально не прописано в ТЗ. Все равно это не будет работать.
Так что ещё один важный вывод из ситцуации который нужно было сделать: Должны быть нормальные взаимоотношения с клиентом, без попыток втоптать друг друга в грязь и/или подставить на деньги.
Что-то я таких статей не припоминаю ( может с памятью моей что-то стало?
И как у всякого менеджера, его главная обязанность организация совместной деятельности группы людей необходимой для достижения некой цели.
Все остальное является побочными видами деятельности.
Он может быть одновременно разработчиком (или тестером, у тестеров тоже есть Team lead-ы) а может и не быть.
Он может совмещать роль архитектора или может доверить исполнение этой роли кому-то из своей команды.
Может быть самым квалифицированным специалистом своей команды, но это не обязательно.
Может быть самым умным, но если он будет опиратся при принятии решений в том числе на мнение более умных подчиненных, этого не требуется.
Чего он точно не может делать, это уклонятся от решения возникающих на пути к общей цели проблем.
Не может перекладывать отвественность за общие неудачи на другого.
Обязан добится приличной награды для подчиненного который снова сделал невозможное.
Ну а в целом про роль менеджера столько написано что нет смысла пересказывать.
Учите работы классиков и у Вас все получится )
Поднимитесь еще на одну ступеньку и почувствуете что эта должность еще более неблагодарная ))) Определенности в обязанностях еще меньше, а конкуренция за позицию неожиданно суровая и т.п.
Фронтальный = для взаимодействия с конечными потребителями, колцентры, веб-сайт, мобильные приложения и тп
Базис = значит что вместо того чтобы взять и интегрировать несколько готовых систем для веб сайта, колцентра и MA люди взялись за написание своего велосипеда… то есть платформы который умеет все это вместе в одном флаконе. Кому жалко денег так не делают…
Омниканальные процессы = это значит что при звонке в колнецтр Вас не должны спрашивать какую Карту вы оформили в офисе. А в мобильном приложении после регистрации Вас как пользователя, она должны отображается автоматически. То есть действие инициированное клиентом в одном из каналов Мобильное приложение, Офис, веб сайт или колцентр должно иметь продолжение в
Так же интересно какие KPI используются для разработки? Надеюсь они напрямую влияют на зарплату каждого разработчика и это что-то отлично проверенное временем типа CLOC?
Поддерживается ли ACID?
Что вообще происходит при конкурентной записи в таблицы? Поддерживается ли read consistency?
Вообще люди часто раскрываются именно в составе команды и в процессе работы над проектом и ценными они являются именно как часть команды и в контексте проекта. Но то есть в звёзд которые сами по себе звезды я не очень верю. Хотя наш HR думает что именно такие люди нам нужны…
Darwin а позднее OS/X а ещё позднее снова macOS построен на ядре FreeBSD, настоящем Unix-е )
Хотя надо признать выбрали его как основу OS скорее из за лицензии, так как BSD лицензия позволяет не раскрывать код производных продуктов.