なぜ私たちはTKを構成しないのですか。 その見返りは?

さまざまな開発方法があります。 誰もが開発会社に最適なアプローチを選択します。 独自の方法論の基礎として、エクストリームプログラミング(XP)を使用しています。 もちろん、私たちはそれに独自の変更を加えましたが、今日はそれについてお話ししたくありません。







すべてのプロジェクトは、技術的なタスクから始まります。 それで、それは以前であり、多くの人にとって、それは今まで公理のままです。 これは悪くありませんが、TKをほぼ完全に放棄しました。 今では、以前はほとんど無駄に費やされていた膨大な時間が削減されます。



ユーザーはToRを作成する必要があります



TKを構築する最も非効率的な方法は、ユーザーと通信することです。 しかし、プログラムはユーザー向けに書かれているため、どうでしょう。 はい、プログラムはユーザー向けに書かれていますが、ユーザー向けではありません。 毎日コンベアでナットを締めているある労働者を想像してください。 ナットを締めやすくするために何をする必要があるのか​​を彼に尋ねます。 彼は、ナットでそれらを取得するために正しい位置に配置する必要のない自動調整キーを作成することが望ましいと言うでしょう。 ナット自体を回すキー、コンベアの近くに立たないように快適な椅子などが必要です。 あなたはすべての願いを注意深く書き留め、仕事の声明に提出します。 結局のところ、実際のユーザーの問題を解決しているのです! あなたは2番目の労働者に行きます、そして、彼はあなたが仕事中に軽食をとることができるように、職場の近くで水栓とサンドイッチを備えた冷蔵庫を作ることが良いだろうとあなたに言います。 誰もが3番目の1つに満足しています。結局のところ、ミュージシャンだけが必要なのです。



それで、労働者のすべての願いを書き留めました。 問題は、企業の観点からユーザーの緊急の問題を解決することの有効性は何ですか? ゼロ付近で変動すると思います。 すべてのボタンを青色で塗り直すのと同じです。 彼らは何かをしたようですが、それの良い点は...



TKに行く必要があるのは誰ですか?



プロセスを構築する人に。 これらは、部門の長、チーフの長、計画部門などです。



従業員は自分のプロセスのみを知っており、それでも上から彼に課せられます。 上司は、部下のすべての従業員のプロセスと、他の部門とのやり取りのプロセスを知っています。 それが重要です。 そもそも、プログラムの機能をビジネスプロセスに置き換えるのではなく、コードで実装することを試みる価値があります。 その後、プログラムは意味をなして使用されます。 それ以外の場合は、全員が1か月以内、またはそれよりも早くデスクドロワーに送られます。 Google Waveが問題を解決しなかったという理由だけでユーザーに受け入れられなかったように思えますが、プロセスに焦点を合わせました。 現実から隔離されたものとしてのプロセス自体は、ほとんど関心がありません。



繰り返しますが、これらの人々を最大限に活用しようとしないでください。 単純な部門長の代わりになります。 部下の意識、行動、決定の流れの混乱の混乱の中で脆弱な秩序を維持することに加えて、彼は文書を作成する必要があります。彼にとっては、彼は単なる三流ではなく、一般的に執行事項の地平線をはるかに超えています。 そして、あなたが彼らに尋ねる質問は、「鼻を摘むプロセスについて詳しく教えてください」というタイプの質問と同等です。 あなたは話すことができますが、与えられた時間にこれらの会話はお金をもたらしません。



ビジネスプロセスが形式化されていない場合はどうなりますか?



次に、自分で作成する必要があります。 はい、ビジネスプロセスを顧客に提供する必要があるのは開発者です。 これを行うには、クライアントの作業方法の研究に時間を費やし、問題を掘り下げ、自動化の重要なポイントを決定する必要があります。 提案は、いくつかの一般的な要件の形式化時だけでなく、開発段階全体で行う必要があります。 各開発者は、例外なく、なぜ自分が何かをしているのか、その理由は何か、どのようなビジネスプロセスがコードに組み込まれているのかを知る必要があります。



私の意見では、最も理想的な顧客は、自分のプロセスを自動化するだけでなく、自動化の最大の効果を達成するためにそれらを再編成することもあなたに信頼している顧客です。 逆説的に聞こえますが、自動化の最も成功した例は、TKが最小の場合に得られます。 大切なボタン「Make beautiful」のようなものです。



雄弁なプロトタイプ



プロトタイプ以上に顧客の要求の形式化を刺激するものはありません。 彼は、生産プロセスの内部組織のすべての魅力と欠点を明確に示しています。 私なしでプロトタイプについて十分に書かれているので、私はそこで止まりません。



しかし、TKなしではどうですか?



TKをいくつかの問題マップに置き換えました。 これは、フリースタイルで書かれたソリューションのタスクの概要です。 問題を解決した=契約を満たした。 すべてがシンプルです。



開発時には、私たちは顧客の会社の部署になり、同時に単一の結果を出すようになりました。 タスクの共同作業により、顧客は短いTKの形式化に関する考えを合理化することを考えるようになりますが、同時に、ビジネスを行う日々の作業にあまり干渉しません。 そのような控えめな開発が判明しました。



まとめると



もちろん、これはすべての病気に対する特効薬ではなく、万能薬でもありません。 誰もが事業開発において独自の道を選択し、現在の市場状況に最適なソリューションを探す必要があります。



あなたのビジネスで頑張ってください!



All Articles